Java基础知识整理(一)

最近准备面试资料,针对常见的Java基础知识做出整理与复习。

Synchronized

synchronizedjava提供的原子性内置锁,这种内置的并且使用者看不到的锁也被称为监视器锁,使用synchronized之后,会在编译之后在同步的代码块前后加上monitorentermonitorexit字节码指令,他依赖操作系统底层互斥锁实现。他的作用主要就是实现原子性操作和解决共享变量的内存可见性问题。

执行monitorenter指令时会尝试获取对象锁,如果对象没有被锁定或者已经获得了锁,锁的计数器+1。此时其他竞争锁的线程则会进入等待队列中。

执行monitorexit指令时则会把计数器-1,当计数器值为0时,则锁释放,处于等待队列中的线程再继续竞争锁。

synchronized是排它锁,当一个线程获得锁之后,其他线程必须等待该线程释放锁后才能获得锁,而且由于Java中的线程和操作系统原生线程是一一对应的,线程被阻塞或者唤醒时时会从用户态切换到内核态,这种转换非常消耗性能。

从内存语义来说,加锁的过程会清除工作内存中的共享变量,再从主内存读取,而释放锁的过程则是将工作内存中的共享变量写回主内存。

理解ReentrantLock原理

相比于synchronizedReentrantLock需要显式的获取锁和释放锁。

  1. 等待可中断,当持有锁的线程长时间不释放锁的时候,等待中的线程可以选择放弃等待,转而处理其他的任务。
  2. 公平锁:synchronizedReentrantLock默认都是非公平锁,但是ReentrantLock可以通过构造函数传参改变。只不过使用公平锁的话会导致性能急剧下降。
  3. 绑定多个条件:ReentrantLock可以同时绑定多个Condition条件对象。

Volatile

使用volatile声明的变量,可以确保值被更新的时候对其他线程立刻可见。volatile使用内存屏障来保证不会发生指令重排,解决了内存可见性的问题。

ThreadLocal

ThreadLocal可以理解为线程本地变量,他会在每个线程都创建一个副本,那么在线程之间访问内部副本变量就行了,做到了线程之间互相隔离,相比于synchronized的做法是用空间来换时间。

Happens-Before

示例一
1
2
3
4
5
6
7
8
9
10
11
12
13
14
class VolatileExample {
int x = 0;
volatile boolean v = false;
public void writer() {
x = 42;
v = true;
}

public void reader() {
if (v == true) {
//x的值是多少呢?
}
}
}

假设线程A执行writer()方法,按照volatile会将v=true写入内存;线程B执行reader()方法,按照volatile,线程B会从内存中读取变量v,如果线程B读取到的变量vtrue,那么,此时的变量x的值是多少呢?

这个示例程序给人的直觉就是x的值为42,其实,x的值具体是多少和JDK的版本有关,如果使用的JDK版本低于1.5,则x的值可能为42,也可能为0。如果使用1.51.5以上版本的JDK,则x的值就是42

看到这个,就会有人提出问题了?这是为什么呢?其实,答案就是在JDK1.5版本中的Java内存模型中引入了Happens-Before原则。

示例二
1
2
3
4
5
6
7
8
9
10
public class Test{
private int x = 0;
public void initX{
synchronized(this){ //自动加锁
if(this.x < 10){
this.x = 10;
}
} //自动释放锁
}
}
示例三
1
2
3
4
5
6
7
8
//在线程A中初始化线程B
Thread threadB = new Thread(()->{
//此处的变量x的值是多少呢?答案是100
});
//线程A在启动线程B之前将共享变量x的值修改为100
x = 100;
//启动线程B
threadB.start();
示例四
1
2
3
4
5
6
7
8
9
Thread threadB = new Thread(()-{
//在线程B中,将共享变量x的值修改为100
x = 100;
});
//在线程A中启动线程B
threadB.start();
//在线程A中等待线程B执行完成
threadB.join();
//此处访问共享变量x的值为100
示例五
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//在线程A中将x变量的值初始化为0
private int x = 0;

public void execute(){
//在线程A中初始化线程B
Thread threadB = new Thread(()->{
//线程B检测自己是否被中断
if (Thread.currentThread().isInterrupted()){
//如果线程B被中断,则此时X的值为100
System.out.println(x);
}
});
//在线程A中启动线程B
threadB.start();
//在线程A中将共享变量X的值修改为100
x = 100;
//在线程A中中断线程B
threadB.interrupt();
}
示例六
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class TestThread {

public TestThread(){
System.out.println("构造方法");
}

@Override
protected void finalize() throws Throwable {
System.out.println("对象销毁");
}

public static void main(String[] args){
new TestThread();
System.gc();
}
}

【原则一】程序次序规则

在一个线程中,按照代码的顺序,前面的操作Happens-Before于后面的任意操作。

同一个线程中,程序在前面对某个变量的修改一定是对后续操作可见的。例如【示例一】中的程序x=42会在v=true之前执行。

【原则二】volatile变量规则

对一个volatile变量的写操作,Happens-Before于后续对这个变量的读操作。

对一个使用了volatile变量的写操作,先行发生于后面对这个变量的读操作。

【原则三】传递规则

如果A Happens-Before B,并且B Happens-Before C,则A Happens-Before C

合【原则一】、【原则二】和【原则三】再来看【示例一】程序,此时,我们可以得出如下结论:

(1)x = 42 Happens-Before 写变量v = true,符合【原则一】程序次序规则。

(2)写变量v = true Happens-Before 读变量v = true,符合【原则二】volatile变量规则。

再根据【原则三】传递规则,我们可以得出结论:x = 42 Happens-Before 读变量v=true

【原则四】锁定规则

对一个锁的解锁操作 Happens-Before于后续对这个锁的加锁操作。

【示例二】,假设变量x的值为10,线程A执行完synchronized代码块之后将x变量的值修改为10,并释放synchronized锁。当线程B进入synchronized代码块时,能够获取到线程Ax变量的写操作,也就是说,线程B访问到的x变量的值为10

【原则五】线程启动规则

如果线程A调用线程B的start()方法来启动线程B,则start()操作Happens-Before于线程B中的任意操作。

线程A启动线程B之后,线程B能够看到线程A在启动线程B之前的操作。

【示例三】线程A启动线程B之后,线程B能够看到线程A在启动线程B之前的操作,在线程B中访问到的x变量的值为100。

【原则六】线程终结规则

线程A等待线程B完成(在线程A中调用线程Bjoin()方法实现),当线程B完成后(线程A调用线程Bjoin()方法返回),则线程A能够访问到线程B对共享变量的操作。

参见【示例四】。

【原则七】线程中断规则

对线程interrupt()方法的调用Happens-Before于被中断线程的代码检测到中断事件的发生。

【示例五】,在线程A中中断线程B之前,将共享变量x的值修改为100,则当线程B检测到中断事件时,访问到的x变量的值为100。

【原则八】对象终结规则

一个对象的初始化完成Happens-Before于它的finalize()方法的开始。

运行结果如下所示。

1
2
构造方法
对象销毁

理解run/start方法

start方法

  • 用来启动线程的方法,属于Thread类。
  • 调用start方法之后,无需等待run方法体代码执行完毕,直接继续执行主线程下面的代码。
  • 调用start方法启动一个线程,此时线程会处于就绪状态,并没有运行,一旦得到cpu时间片,就会开始执行线程的run方法,这里的run方法被称为线程体,它包含了要执行的线程的内容,run方法运行结束,线程随即终止。

run方法

  • run方法是类的一个普通方法。
  • 直接调用run方法,程序依旧在主线程中运行,并不会启动线程。
  • run方法必须是public访问权限,返回值为void的普通方法。

理解sleep/wait/notify/notifyall/countdownlatch

sleep方法

  • sleep方法属于Thread类的静态本地方法,调用方式为Thread.sleep(long millis)
  • sleep方法用于当前线程休眠,并且时间到了之后,当前线程会继续执行,并且sleep只能自动醒来,不能被唤醒。
  • sleep方法一般用于当前线程的暂停或者休眠。
  • sleep方法不会释放锁。
  • sleep会让出cpu执行时间,强制上下文切换。

wait方法

  • wait方法属于Object类的本地方法,调用方式为xxx.wait(long millis)
  • wait方法必须在synchronized块中使用(解决lost wake up问题),也即wait应该在同步代码块中使用。
  • wait一般用于多线程之间的通信。
  • wait方法会释放锁。

notify方法

  • notify方法属于Object类的本地方法,调用方式为xxx.notify()

  • notify方法随机唤醒一个处于wait的线程。

  • notify方法并不会立马释放锁,必须等到synchronized方法或者代码块执行完毕之后,才会真正释放锁。

notifyall方法

  • notifyall方法属于Object类的本地方法,调用方式为xxx.notifyall()
  • notifyall方法会唤醒所有处于wait的线程,共同竞争锁,只有真正获取到锁对象的线程才能继续执行。
  • notifyall方法并不会立马释放锁,必须等到synchronized方法或者代码块执行完毕之后,才会真正释放锁。

countdownlatch方法

  • countdownlatch方法用于多线程之间的同步。
  • 主要有两个方法await()与countDown()。
  • await()方法使调用线程处于等待状态,并且可以有多个线程调用await()方法,多个线程均处于等待状态,以共享模式使用同一把锁。
  • countDown()方法用于使计数器减一,并且允许同一个线程多次调用该方法。
  • 当计数器减为0时,所有处于等待状态的线程,均被唤醒,继续执行。

join方法

  • 属于Thread类的方法。
  • join方法主要用于线程同步,可以让线程执行从串行变为并行。
  • join(10)表示A线程会等待B线程执行10毫秒,join(0)等同于join()表示A线程会等待B线程执行完。

理解Java锁机制

乐观锁与悲观锁

乐观锁

乐观锁:乐观锁认为自己在使用数据时不会有别的线程修改数据,所以不会添加锁,只是在更新数据的时候去判断之前有没有别的线程更新了这个数据。如果这个数据没有被更新,当前线程将自己修改的数据成功写入。如果数据已经被其他线程更新,则根据不同的实现方式执行不同的操作(例如报错或者自动重试)。乐观锁在Java中是通过使用无锁编程来实现,最常采用的是CAS算法,Java原子类中的递增操作就通过CAS自旋实现的。

悲观锁

悲观锁:对于数据的并发操作,悲观锁认为自己在使用数据的时候一定有别的线程来修改数据,因此在获取数据的时候会先加锁,确保数据不会被别的线程修改。Java中,synchronized关键字和Lock的实现类都是悲观锁。

优缺点

  • 悲观锁适合写操作多的场景,先加锁可以保证写操作时数据正确。

  • 乐观锁适合读操作多的场景,不加锁的特点能够使其读操作的性能大幅提升。

悲观锁与乐观锁

自旋锁与适应性自旋锁

自旋锁

自旋锁:阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成(有可能涉及用户态与内核态的切换),这种状态转换需要耗费处理器时间。如果同步代码块中的内容过于简单,状态转换消耗的时间有可能比用户代码执行的时间还要长。

在许多场景中,同步资源的锁定时间很短,为了这一小段时间去切换线程,线程挂起和恢复现场的花费可能会让系统得不偿失。如果物理机器有多个处理器,能够让两个或以上的线程同时并行执行,我们就可以让后面那个请求锁的线程不放弃CPU的执行时间,看看持有锁的线程是否很快就会释放锁。

而为了让当前线程“稍等一下”,我们需让当前线程进行自旋,如果在自旋完成后前面锁定同步资源的线程已经释放了锁,那么当前线程就可以不必阻塞而是直接获取同步资源,从而避免切换线程的开销。这就是自旋锁。

自旋锁本身是有缺点的,它不能代替阻塞。自旋等待虽然避免了线程切换的开销,但它要占用处理器时间。如果锁被占用的时间很短,自旋等待的效果就会非常好。反之,如果锁被占用的时间很长,那么自旋的线程只会白浪费处理器资源。所以,自旋等待的时间必须要有一定的限度,如果自旋超过了限定次数(默认是10次,可以使用-XX:PreBlockSpin来更改)没有成功获得锁,就应当挂起线程。

自旋锁

自适应自旋锁

自适应自旋锁:自适应意味着自旋的时间(次数)不再固定,而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上,自旋等待刚刚成功获得过锁,并且持有锁的线程正在运行中,那么虚拟机就会认为这次自旋也是很有可能再次成功,进而它将允许自旋等待持续相对更长的时间。如果对于某个锁,自旋很少成功获得过,那在以后尝试获取这个锁时将可能省略掉自旋过程,直接阻塞线程,避免浪费处理器资源。

无锁 VS 偏向锁 VS 轻量级锁 VS 重量级锁

这四种锁是指锁的状态,专门针对synchronized的。在介绍这四种锁状态之前还需要介绍一些额外的知识。

首先为什么Synchronized能实现线程同步?在回答这个问题之前我们需要了解两个重要的概念:“Java对象头”、“Monitor”。

Java对象头

以Hotspot虚拟机为例,Hotspot的对象头主要包括两部分数据:Mark Word(标记字段)、Class Pointer(类型指针)。

java对象头

无锁

无锁没有对资源进行锁定,所有的线程都能访问并修改同一个资源,但同时只有一个线程能修改成功。

无锁的特点就是修改操作在循环内进行,线程会不断的尝试修改共享资源。如果没有冲突就修改成功并退出,否则就会继续循环尝试。如果有多个线程修改同一个值,必定会有一个线程能修改成功,而其他修改失败的线程会不断重试直到修改成功。上面我们介绍的CAS原理及应用即是无锁的实现。无锁无法全面代替有锁,但无锁在某些场合下的性能是非常高的。

偏向锁

偏向锁是指一段同步代码一直被一个线程所访问,那么该线程会自动获取锁,降低获取锁的代价。

在大多数情况下,锁总是由同一线程多次获得,不存在多线程竞争,所以出现了偏向锁。其目标就是在只有一个线程执行同步代码块时能够提高性能。

当一个线程访问同步代码块并获取锁时,会在Mark Word里存储锁偏向的线程ID。在线程进入和退出同步块时不再通过CAS操作来加锁和解锁,而是检测Mark Word里是否存储着指向当前线程的偏向锁。引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径,因为轻量级锁的获取及释放依赖多次CAS原子指令,而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令即可。

偏向锁只有遇到其他线程尝试竞争偏向锁时,持有偏向锁的线程才会释放锁,线程不会主动释放偏向锁。偏向锁的撤销,需要等待全局安全点(在这个时间点上没有字节码正在执行),它会首先暂停拥有偏向锁的线程,判断锁对象是否处于被锁定状态。撤销偏向锁后恢复到无锁(标志位为“01”)或轻量级锁(标志位为“00”)的状态。

轻量级锁

当锁是偏向锁的时候,被另外的线程所访问,偏向锁就会升级为轻量级锁,其他线程会通过自旋的形式尝试获取锁,不会阻塞,从而提高性能。

在代码进入同步块的时候,如果同步对象锁状态为无锁状态(锁标志位为“01”状态,是否为偏向锁为“0”),虚拟机首先将在当前线程的栈帧中建立一个名为锁记录(Lock Record)的空间,用于存储锁对象目前的Mark Word的拷贝,然后拷贝对象头中的Mark Word复制到锁记录中。

拷贝成功后,虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针,并将Lock Record里的owner指针指向对象的Mark Word。

如果这个更新动作成功了,那么这个线程就拥有了该对象的锁,并且对象Mark Word的锁标志位设置为“00”,表示此对象处于轻量级锁定状态。

如果轻量级锁的更新操作失败了,虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧,如果是就说明当前线程已经拥有了这个对象的锁,那就可以直接进入同步块继续执行,否则说明多个线程竞争锁。

若当前只有一个等待线程,则该线程通过自旋进行等待。但是当自旋超过一定的次数,或者一个线程在持有锁,一个在自旋,又有第三个来访时,轻量级锁升级为重量级锁。

重量级锁

升级为重量级锁时,锁标志的状态值变为“10”,此时Mark Word中存储的是指向重量级锁的指针,此时等待锁的线程都会进入阻塞状态。

公平锁与非公平锁

公平锁:公平锁是指多个线程按照申请锁的顺序来获取锁,线程直接进入队列中排队,队列中的第一个线程才能获得锁。公平锁的优点是等待锁的线程不会饿死。缺点是整体吞吐效率相对非公平锁要低,等待队列中除第一个线程以外的所有线程都会阻塞,CPU唤醒阻塞线程的开销比非公平锁大。

公平锁

非公平锁:非公平锁是多个线程加锁时直接尝试获取锁,获取不到才会到等待队列的队尾等待。但如果此时锁刚好可用,那么这个线程可以无需阻塞直接获取到锁,所以非公平锁有可能出现后申请锁的线程先获取锁的场景。非公平锁的优点是可以减少唤起线程的开销,整体的吞吐效率高,因为线程有几率不阻塞直接获得锁,CPU不必唤醒所有线程。缺点是处于等待队列中的线程可能会饿死,或者等很久才会获得锁。

非公平锁

可重入锁与不可重入锁

可重入锁

可重入锁:可重入锁又名递归锁,是指在同一个线程在外层方法获取锁的时候,再进入该线程的内层方法会自动获取锁(前提锁对象得是同一个对象或者class),不会因为之前已经获取过还没释放而阻塞。Java中ReentrantLock和synchronized都是可重入锁,可重入锁的一个优点是可一定程度避免死锁。

可重入锁

不可重入锁

不可重入锁:不可重入锁,是指在同一个线程在外层方法获取锁的时候,再进入该线程的内层方法会再次获取锁,实际上该对象锁已被当前线程所持有,且无法释放。所以此时会出现死锁。

不可重入锁

互斥锁与共享锁

互斥锁

互斥锁:是指该锁一次只能被一个线程所持有。如果线程获得临界资源的互斥锁之后,其它线程则不能再对临界资源加锁。获得互斥锁的线程即能读数据又能修改数据。JDK中的synchronized和JUC中Lock的实现类就是互斥锁。

共享锁

共享锁:共享锁是指该锁可被多个线程所持有。如果线程对临界资源加上共享锁后,则其他线程可以继续对临界资源加共享锁,不能加排它锁。获得共享锁的线程只能读数据,不能修改数据。

引用类型

Java集合

Java集合的继承关系

collection继承关系图

集合继承关系图

map继承关系图

map继承关系图

Array与Linked

形式为ArrayXXX与LinkedXXX,例如ArrayList/LinkedList,ArrayBlockingQueue/LinkedBlockingQueue,其中Array开头的为顺序结构,Linked开头的为链式结构。

RandomAccess

随机访问类,继承此类的集合支持随机访问,一般底层结果为数组,也即顺序存储,因此支持随机访问。

Queue与Deque

队列与双端队列,普通队列,先进先出,队尾入队,对首出队,双端队列,两端均可入队与出队。

BlockingQueue

阻塞队列,常用于多线程环境,如果入队时队列已满或者出队时队列已空,则会阻塞线程,类似生产者与消费者模型。

DelayQueue

延迟队列,继承了BlockingQueue,只有延迟时间到了之后,才能从队列中获取元素,并且DelayQueue没有大小限制,因此生产者不会阻塞,但是消费者会阻塞。

SynchronousQueue

无缓冲等待队列,没有容量,是一个不存储元素的阻塞队列,会直接将任务交给消费者,必须等队列中的添加元素被消费后才能继续添加新的元素。

Priority

PriorityXXX,例如PriorityQueue与PriorityBlockingQueue,相对正常的队列,Priority队列的元素会带有优先级,出队时会根据元素优先级决定出队顺序。PriorityQueue底层是使用二叉堆实现的,根据需要可以是小根堆或者大根堆。

Concurrent

ConcurrentXXX,例如ConcurrentHashMap等,是Java后来引入的并发包中的集合,多用于多线程场景,解决线程安全问题。

CopyOnWrite

CopyOnWriteXXX,例如CopyOnWriteArrayList与CopyOnWriteArraySet等等,主题思想是写入时复制,当有多个调用者同时去请求一个资源时,当其中一个调用者要对资源进行修改,系统会copy一个副本给该调用者,让其进行修改;而其他调用者所拥有资源并不会由于该调用者对资源的改动而发生改变。简单的理解,就是当我们往CopyOnWrite容器中添加元素时,不直接操作当前容器,而是先将容器进行Copy,然后对Copy出的新容器进行修改,修改后,再将原容器的引用指向新的容器,即完成了整个修改操作。

Sorted

SortedXXX,例如SortedSet与SortedMap等等,这些一般属于排序接口或者抽象类,继承这些对象的集合一般附带顺序。

IdentityHashMap

在比较Key时,HashMap一般会使用equal比较而IdentityHashMap使用==比较,也即HashMap比较的是值是否相等,而IdentityHashMap比较的是引用是否相等。并且IdentityHashMap解决哈希冲突的方法不同于HashMap的链地址法,而是线性探测法。

WeakHashMap

与HashMap类似,区别在于使用弱引用关联map中存储的数据,通过该类实现缓存,在内存紧张的情况下,可以避免强引用占用大量内存。

名词解释

内存屏障

内存屏障,也称内存栅栏,内存栅障,屏障指令等,是一类同步屏障指令,它使得CPU 或编译器在对内存进行操作的时候, 严格按照一定的顺序来执行, 也就是说在memory barrier 之前的指令和memory barrier之后的指令不会由于系统优化等原因而导致乱序。
大多数现代计算机为了提高性能而采取乱序执行,这使得内存屏障成为必须。
语义上,内存屏障之前的所有写操作都要写入内存;内存屏障之后的读操作都可以获得同步屏障之前的写操作的结果。因此,对于敏感的程序块,写操作之后、读操作之前可以插入内存屏障。

附录

美团Java锁博客