杂谈（一）

Jitorun
113 阅读21分钟

Unicode 和 ASCII 码的区别？

  • ASCII：ASCII码一共规定了128个字符的编码，对英语字符与二进制位之间的关系，做了统一规定，只占用了一个字节的后面7位，最前面的1位统一规定为0。

  • Unicode：是一种所有符号的编码，Unicode只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储

  • 这里就有两个严重的问题，第一个问题是，如何才能区别Unicode和ASCII？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？第二个问题是，我们已经知道，英文字母只用一个字节表示就够了，如果Unicode统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是0，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的。

  • UTF-8就是在互联网上使用最广的一种Unicode的实现方式。其他实现方式还包括UTF-16（字符用两个字节或四个字节表示）和UTF-32（字符用四个字节表示），不过在互联网上基本不用。重复一遍，这里的关系是，UTF-8是Unicode的实现方式之一。

  • UTF-8的编码规则很简单，只有二条：

    1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。

    2）对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。

  • UTF-8英文字符占1字节，中文占3字节

进程与线程的区别与关系

  • 一个进程中至少包含一个线程，线程不能独立于进程而存在.
  • 进程是正在运行程序的实例，进程中包含线程
  • 进程是操作系统分配资源的基本单位，线程是操作系统调度的基本单位
  • 进程之间不能共享资源，线程可以共享进程的资源（JVM中有提到线程共享堆与方法区，而对于java虚拟机栈与本地方法栈和程序计数器是自己私有的）
  • 线程上下文切换速度快，进程上下文切换速度慢

进程之间通信方式

  • 管道：简单，但是效率低
  • 消息队列：在管道中，其大小受限且只能承载无格式字节流的方式，而消息队列允许不同进程以消息队列的形式发送给任意的进程。消息队列在发送数据的时候，按照一个个独立单元(消息体)进行发送，其中每个消息体规定大小块，同时发送方和接收方约定好消息类型或者正文的格式。
  • 共享内存：每个进程都有自己的虚拟内存空间，不同的进程映射到不同的物理内存空间。那么我们可以申请一块虚拟地址空间，不同进程通过这块虚拟地址空间映射到相同的屋里地址空间，这样不同进程就可以及时的感知进程都干了啥，就不需要再拷贝来拷贝去。
  • 信号量：对于共享内存，问题来了，这么多进程都共享这块内存，如果同时都往里面写内容，难免会出现冲突的现象，比如A进程写了数字5，B进程同样的地址写了6就直接给覆盖了，这样就不友好了，为了防止冲突，我们得有个约束或者说一种保护机制。使得同一份共享的资源只能一个进程使用，这里就出现了信号量机制，信号量主要实现进程之间的同步和互斥，(PV)。
  • 信号：在操作系统中，不同信号用不同的值表示，每个信号设置相应的函数，一旦进程发送某一个信号给另一个进程，另一进程将执行相应的函数进行处理。也就是说先把可能出现的异常等问题准备好，一旦信号产生就执行相应的逻辑即可。
  • 套接字

死锁与死锁产生的条件

  • 死锁：死锁是指两个或两个以上的进程（线程）在运行过程中因争夺资源而造成的一种僵局
  • 死锁产生的4个必要条件 1、互斥： 某种资源一次只允许一个进程访问，即该资源一旦分配给某个进程，其他进程就不能再访问，直到该进程访问结束。 2、占有且等待： 一个进程本身占有资源（一种或多种），同时还有资源未得到满足，正在等待其他进程释放该资源。 3、不可抢占： 别人已经占有了某项资源，你不能因为自己也需要该资源，就去把别人的资源抢过来。 4、循环等待： 存在一个进程链，使得每个进程都占有下一个进程所需的至少一种资源。

Java线程优先级

每个线程都有优先级，优先级的高低只和线程获得执行机会的次数多少有关。并非线程优先级越高的就一定先执行，哪个线程的先运行取决于CPU的调度默认情况下main线程具有普通的优先级，而它创建的线程也具有普通优先级。hread对象的setPriority(int x)和getPriority()来设置和获得优先级。

MAX_PRIORITY :值是10

MIN_PRIORITY :值是1

NORM_PRIORITY :值是5(主方法默认优先级)

每个线程默认的优先级都与创建他的父线程的优先级相同

Java中的原子操作

原子操作是指一个或者多个不可再分割的操作。这些操作的执行顺序不能被打乱，这些步骤也不可以被切割而只执行其中的一部分（不可中断性）

在Java中，我们可以通过同步锁或者CAS操作来实现原子操作。

  • CAS：CAS是Compare and swap的简称，这个操作是硬件级别的操作，在硬件层面保证了操作的原子性。CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做
  • CAS操作存在问题
    • ABA问题:因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A－B－A 就会变成1A-2B－3A。（从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。）
    • 循环时间长开销大：自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。
    • 只能保证一个共享变量的原子操作：当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。

Java volatile 关键字

一旦一个共享变量（类的成员变量、类的静态成员变量）被volatile修饰之后，那么就具备了两层语义：

  • 保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。

  • 禁止进行指令重排序。

volatile关键字禁止指令重排序有两层意思：

  • 当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行；

  • 在进行指令优化时，不能将在对volatile变量访问的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。

面这段话摘自《深入理解Java虚拟机》：

　　“观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令”

lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），内存屏障会提供3个功能：

  • 它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操作已经全部完成；

  • 它会强制将对缓存的修改操作立即写入主存；

  • 如果是写操作，它会导致其他CPU中对应的缓存行无效。

Happens-Before原则

happens-before原则（先行发生原则）：

  • 程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作
  • 锁定规则：一个unLock操作先行发生于后面对同一个锁的lock操作
  • volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作
  • 传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C
  • 线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作
  • 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生
  • 线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行
  • 对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始

读写锁

  • 如果当前没有写锁或读锁时，第一个获取锁的线程都会成功，无论该锁是写锁还是读锁。
  • 如果当前已经有了读锁，那么这时获取写锁将失败，获取读锁有可能成功也有可能失败
  • 如果当前已经有了写锁，那么这时获取读锁或写锁，如果线程相同（可重入），那么成功；否则失败（可重入就是说某个线程已经获得某个锁，可以再次获取锁而不会出现死锁）

进程栈与线程栈

关于进程栈和线程栈总结：

（1）进程栈大小时执行时确定的

（2）进程栈大小是随机确认的，至少比线程栈要大，但不会超过2倍

（3）线程栈是固定大小的，可以使用ulimit -a 查看，使用ulimit -s 修改

进程栈的初始化大小是由编译器和链接器计算出来的，但是栈的实时大小并不是固定的，Linux 内核会根据入栈情况对栈区进行动态增长（其实也就是添加新的页表）。但是并不是说栈区可以无限增长，它也有最大限制

而线程栈不能动态增长，一旦用尽就没了

交换机和路由器各自在哪一层

交换机在数据链路层，路由器在网络层

IP、TCP、UDP首部详解

参考blog.csdn.net/zhangliangz…

TCP 滑动窗口解释一下作用

滑动窗口的作用主要有两点。

1：流量控制： 发送的字节不能超过窗口的大小。窗口的大小是变动的，应用程序根据自身性能状况(如内存不足)实时通知tcp协议栈要缩小窗口的大小。窗口大小一般为一个16bit位字段。

2：保证TCP可靠(确认重传)：tcp是双工的，所以任意一端都维护着一个发送窗口和接收窗口。发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界；接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。

慢开始与快重传

拥塞控制常用方法：

  1. 慢开始、拥塞控制

  2. 快重传、快恢复

    一切的基础还是慢开始，这种方法的思路是这样的：

    1. 发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口；
    2. 当主机开始发送数据时，避免一下子将大量字节注入到网络，造成或者增加拥塞，选择发送一个1字节的试探报文
    3. 当收到第一个字节的数据的确认后，就发送2个字节的报文；
    4. 若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级；
    5. 最后会达到一个提前预设的“慢开始门限”，接下来每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长
    6. 当出现网络拥塞，比如丢包时，将慢开始门限设为原先的一半，然后将cwnd设为1，执行慢开始算法

快重传的机制是：

  • 接收方建立这样的机制，如果一个包丢失，则对后续的包继续发送针对该包的重传请求；
  • 一旦发送方接收到三个一样的确认，就知道该包之后出现了错误，立刻重传该包
  • 此时发送方开始执行“快恢复”算法：
    • 慢开始门限减半
    • cwnd设为慢开始门限减半后的数值
    • 每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长

事务的ACID

谈到事务一般都是以下四点:

  • 原子性（Atomicity）

原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。实现主要基于undo log日志实现的。

undo log：实现原子性的关键，是当事务回滚时能够撤销所有已经成功执行的sql语句。 当事务对数据库进行修改时，InnoDB会生成对应的undo log；如果事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。

undo log属于逻辑日志，它记录的是sql执行相关的信息。当发生回滚时，InnoDB会根据undo log的内容做与之前相反的工作： 对于每个insert，回滚时会执行delete； 对于每个delete，回滚时会执行insert； 对于每个update，回滚时会执行一个相反的update，把数据改回去。

  • 一致性（Consistency）

是指应用层系统从一种正确的状态，在事务成功后，达成另一种正确的状态。比如：A、B账面共计100W，A向B转账，加上事务控制，转成功后，他们账户总额应还是100W，事务应保持这种应用逻辑正确一致。还有，转账（事务成功）前后，数据库内部的数据结构--比如账户表的主键、外键、列必须大于0、Btree、双向链表等约束需要是正确的，和原来一致的。

  • 隔离性（Isolation）

隔离是指当多个事务提交时，让它们按顺序串行提交，每个时刻只有一个事务提交。但隔离处理并发事务，效率很差。所以SQL标准制作者妥协了，提出了4种事务隔离等级（1，read-uncommited 未提交就读，可能产生脏读 2，read-commited 提交后读 可能产生不可重复读 3，repeatable-read 可重复读 可能产生幻读 4，serializable 序列化，最高级别，按顺序串行提交），InnoDB默认的隔离级别是可重复读（repeatable red,RR），RR的实现主要基于锁机制、数据的隐藏列、undo log和类next-key lock机制。

123.png

  • 持久性（Durability）

持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响，实现主要基于redo log日志。

redo log：是InnoDB引擎层的日志，用来记录事务操作引起数据的变化，记录的是数据页的物理修改。

7081994-ca1c51a924d2b871.webp

从图中可以看出，在最后提交事务的时候，需要有3个步骤：

  • 写入redo log，处于prepare状态
  • 写binlog
  • 修改redo log状态为commit ps: redo log的提交分为prepare和commit两个阶段，所以称之为两阶段提交

CAP 定理说一下，一般选择牺牲哪些特性？

CAP定理又称CAP原则，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。

取舍策略

CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：

CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。

CP without A：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

类、接口、抽象类的关系

类与抽象类的异同之处

类和抽象类的区别

  • 类可以实例化对象，而抽象类不能实例化对象。

类和抽象类的相同之处

  • 抽象类除了不能实例化对象之外，类的其他功能仍然存在，成员变量、成员方法和构造方法的访问方式和普通类一样。

  • 因为抽象类不能实例化对象，所以抽象类必须被继承，才能被使用。

  • 在Java中抽象类表示的是一种继承关系，一个类只能继承一个抽象类，而一个类却可以实现多个接口。

  • 抽象类中可以有抽象方法和普通方法。

接口与类的异同之处

  • 接口（interface），在Java编程语言中是一个抽象类型，是抽象方法的集合，接口通常以interface来声明。

  • 接口和类属于不同的概念，类是描述对象的属性和方法，接口是包含类要实现的方法。

  • 除非实现接口的类是抽象类，否则该类要定义接口中的所有方法。

  • 接口无法被实例化，但是可以被实现。一个实现接口的类，必须实现接口内所描述的所有方法，否则就必须声明为抽象类。

接口与类相似点

  • 一个接口可以有多个方法。
  • 接口文件保存在 .java 结尾的文件中，文件名使用接口名。
  • 接口的字节码文件保存在 .class 结尾的文件中。
  • 接口相应的字节码文件必须在与包名称相匹配的目录结构中。 接口与类的区别
  • 接口不能用于实例化对象，而类可以。
  • 接口没有构造方法，类中有构造方法。
  • 接口中所有的方法必须是抽象方法，而类中的方法可以是抽象方法，也可以是普通方法。
  • 接口不能包含成员变量，除了 static 和 final 变量。
  • 接口不是被类继承了，而是要被类实现。
  • 接口支持多继承。 接口特性
  • 接口中每一个方法也是隐式抽象的,接口中的方法会被隐式的指定为 public abstract（只能是 public abstract，其他修饰符都会报错）。
  • 接口中可以含有变量，但是接口中的变量会被隐式的指定为 public static final 变量（并且只能是 public，用 private 修饰会报编译错误）。
  • 接口中的方法是不能在接口中实现的，只能由实现接口的类来实现接口中的方法。

抽象类和接口的区别

  • 抽象类中的方法可以有方法体，就是能实现方法的具体功能，但是接口中的方法不行。
  • 抽象类中的成员变量可以是各种类型的，而接口中的成员变量只能是 public static final 类型的。
  • 接口中不能含有静态代码块以及静态方法(用 static 修饰的方法)，而抽象类是可以有静态代码块和静态方法。
  • 一个类只能继承一个抽象类，而一个类却可以实现多个接口。
avatar
文章
阅读
粉丝