auto commit
198
notes/Java 并发.md
|
@ -18,26 +18,20 @@
|
|||
* [线程通信](#线程通信)
|
||||
* [五、线程状态转换](#五线程状态转换)
|
||||
* [六、Executor](#六executor)
|
||||
* [七、volatile](#七volatile)
|
||||
* [保证内存可见性](#保证内存可见性)
|
||||
* [禁止指令重排](#禁止指令重排)
|
||||
* [八、内存模型](#八内存模型)
|
||||
* [1. 硬件的效率与一致性](#1-硬件的效率与一致性)
|
||||
* [2. Java 内存模型](#2-java-内存模型)
|
||||
* [3. 主内存与工作内存](#3-主内存与工作内存)
|
||||
* [4. 内存间交互操作](#4-内存间交互操作)
|
||||
* [5. 内存模型三大特性](#5-内存模型三大特性)
|
||||
* [6. 先行发生原则](#6-先行发生原则)
|
||||
* [九、线程安全](#九线程安全)
|
||||
* [七、内存模型](#七内存模型)
|
||||
* [主内存与工作内存](#主内存与工作内存)
|
||||
* [内存模型三大特性](#内存模型三大特性)
|
||||
* [先行发生原则](#先行发生原则)
|
||||
* [八、线程安全](#八线程安全)
|
||||
* [1. Java 语言中的线程安全](#1-java-语言中的线程安全)
|
||||
* [2. 线程安全的实现方法](#2-线程安全的实现方法)
|
||||
* [十、锁优化](#十锁优化)
|
||||
* [九、锁优化](#九锁优化)
|
||||
* [1. 自旋锁与自适应自旋](#1-自旋锁与自适应自旋)
|
||||
* [2. 锁消除](#2-锁消除)
|
||||
* [3. 锁粗化](#3-锁粗化)
|
||||
* [4. 轻量级锁](#4-轻量级锁)
|
||||
* [5. 偏向锁](#5-偏向锁)
|
||||
* [十一、多线程开发良好的实践](#十一多线程开发良好的实践)
|
||||
* [十、多线程开发良好的实践](#十多线程开发良好的实践)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
@ -427,70 +421,23 @@ for(int i = 0; i < 5; i++) {
|
|||
}
|
||||
```
|
||||
|
||||
# 七、volatile
|
||||
# 七、内存模型
|
||||
|
||||
保证了内存可见性和禁止指令重排,没法保证原子性。
|
||||
|
||||
## 保证内存可见性
|
||||
|
||||
普通共享变量被修改之后,什么时候被写入主存是不确定的。
|
||||
|
||||
volatile 关键字会保证每次修改共享变量之后该值会立即更新到内存中,并且在读取时会从内存中读取值。
|
||||
|
||||
synchronized 和 Lock 也能够保证内存可见性。它们能保证同一时刻只有一个线程获取锁然后执行同步代码,并且在释放锁之前会将对变量的修改刷新到主存当中。不过只有对共享变量的 set() 和 get() 方法都加上 synchronized 才能保证可见性,如果只有 set() 方法加了 synchronized,那么 get() 方法并不能保证会从内存中读取最新的数据。
|
||||
|
||||
## 禁止指令重排
|
||||
|
||||
在 Java 内存模型中,允许编译器和处理器对指令进行重排序,重排序过程不会影响到单线程程序的执行,却会影响到多线程并发执行的正确性。
|
||||
|
||||
volatile 关键字通过添加内存屏障的方式来禁止指令重排,即重排序时不能把后面的指令放到内存屏障之前。
|
||||
|
||||
可以通过 synchronized 和 Lock 来保证有序性,它们保证每个时刻只有一个线程执行同步代码,相当于是让线程顺序执行同步代码,自然就保证了有序性。
|
||||
|
||||
# 八、内存模型
|
||||
|
||||
## 1. 硬件的效率与一致性
|
||||
## 主内存与工作内存
|
||||
|
||||
对处理器上的寄存器进行读写的速度比内存快几个数量级,为了解决这种速度矛盾,在它们之间加入了高速缓存。
|
||||
|
||||
每个处理器都有一个高速缓存,但是所有处理器共用一个主内存,因此高速缓存引入了一个新问题:缓存一致性。当多个处理器的运算都涉及同一块主内存区域时,将可能导致各自的缓存数据不一致。缓存不一致问题通常需要使用一些协议来解决。
|
||||
所有的变量都存储在主内存中,每个线程还有自己的工作内存,工作内存存储在高速缓存中,保存了被该线程使用到的变量的主内存副本拷贝,线程对变量的操作是对其工作内存中的变量进行操作来完成的。
|
||||
|
||||
<div align="center"> <img src="../pics//352dd00d-d1bb-4134-845d-16a75bcb0e02.jpg"/> </div><br>
|
||||
<div align="center"> <img src="../pics//600px-Sharedmem.jpg"/> </div><br>
|
||||
|
||||
除了增加高速缓存之外,为了使得处理器内部的运算单元能尽量被充分利用,处理器可能会对输入代码进行乱序执行(Out-Of-Order Execution)优化,处理器会在计算之后将乱序执行的结果重组,保证该结果与顺序执行的结果是一致的,但并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致,因此,如果存在一个计算任务依赖另外一个计算任务的中间结果,那么其顺序性并不能靠代码的先后顺序来保证。与处理器的乱序执行优化类似,Java 虚拟机的即时编译器中也有类似的指令重排序(Instruction Reorder)优化。
|
||||
|
||||
## 2. Java 内存模型
|
||||
## 内存模型三大特性
|
||||
|
||||
Java 虚拟机规范中试图定义一种 Java 内存模型来屏蔽掉各种硬件和操作系统的内存访问差异,以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。在此之前,主流程序语言(如 C/C++ 等)直接使用物理硬件和操作系统的内存模型,但由于不同平台上内存模型的差异,有可能导致程序在一套平台上并发完全正常,而在另外一套平台上并发访问却经常出错,因此在某些场景就必须针对不同的平台来编写程序。
|
||||
### 1. 原子性
|
||||
|
||||
## 3. 主内存与工作内存
|
||||
|
||||
Java 内存模型的主要目标是定义程序中各个变量的访问规则,即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量(Variables)与 Java 编程中所说的变量有所区别,它包括了实例字段、静态字段和构成数组对象的元素,但不包括局部变量与方法参数,因为后者是线程私有的,不会被共享,自然就不会存在竞争问题。
|
||||
|
||||
Java 内存模型规定了所有的变量都存储在主内存(Main Memory)中。每条线程还有自己的工作内存,线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝,线程对变量的所有操作(读取、赋值等)都必须在工作内存中进行,而不能直接读写主内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量,线程间变量值的传递均需要通过主内存来完成,线程、主内存、工作内存三者的交互关系如图所示。
|
||||
|
||||
<div align="center"> <img src="../pics//b02a5492-5dcf-4a69-9b5b-c2298b2cb81c.jpg"/> </div><br>
|
||||
|
||||
## 4. 内存间交互操作
|
||||
|
||||
Java 内存模型定义了 8 种操作来完成工作内存与主内存之间的交互:一个变量从主内存拷贝到工作内存、从工作内存同步回主内存。虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的。
|
||||
|
||||
- lock(锁定):作用于主内存的变量,它把一个变量标识为一条线程独占的状态。
|
||||
- unlock(解锁):作用于主内存的变量,它把一个处于锁定状态的变量释放出来,释放后的变量才可以被其他线程锁定。
|
||||
- read(读取):作用于主内存的变量,它把一个变量的值从主内存传输到线程的工作内存中,以便随后的 load 动作使用。
|
||||
- load(载入):作用于工作内存的变量,它把 read 操作从主内存中得到的变量值放入工作内存的变量副本中。
|
||||
- use(使用):作用于工作内存的变量,它把工作内存中一个变量的值传递给执行引擎,每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作。
|
||||
- assign(赋值):作用于工作内存的变量,它把一个从执行引擎接收到的值赋给工作内存的变量,每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
|
||||
- store(存储):作用于工作内存的变量,它把工作内存中一个变量的值传送到主内存中,以便随后的 write 操作使用。
|
||||
- write(写入):作用于主内存的变量,它把 store 操作从工作内存中得到的变量的值放入主内存的变量中。
|
||||
|
||||
## 5. 内存模型三大特性
|
||||
|
||||
### 5.1 原子性
|
||||
|
||||
除了 long 和 double 之外的基本数据类型的访问读写是具备原子性的。
|
||||
|
||||
Java 内存模型允许虚拟机将没有被 volatile 修饰的 64 位数据的读写操作划分为两次 32 位的操作来进行,即虚拟机可以不保证 64 位数据类型的 load、store、read 和 write 这 4 个操作的原子性。但是目前各种平台下的商用虚拟机几乎都选择把 64 位数据的读写操作作为原子操作来对待。
|
||||
Java 内存模型允许虚拟机将没有被 volatile 修饰的 64 位数据(long,double)的读写操作划分为两次 32 位的操作来进行,也就是说对这部分数据的操作可以不具备原子性。
|
||||
|
||||
AtomicInteger、AtomicLong、AtomicReference 等特殊的原子性变量类提供了下面形式的原子性条件更新语句,使得比较和更新这两个操作能够不可分割地执行。
|
||||
|
||||
|
@ -508,80 +455,89 @@ public int next() {
|
|||
}
|
||||
```
|
||||
|
||||
如果应用场景需要一个更大范围的原子性保证,Java 内存模型还提供了 lock 和 unlock 操作来满足这种需求,尽管虚拟机未把 lock 和 unlock 操作直接开放给用户使用,但是却提供了更高层次的字节码指令 monitorenter 和 monitorexit 来隐式地使用这两个操作,这两个字节码指令反映到 Java 代码中就是同步块:synchronized 关键字,因此在 synchronized 块之间的操作也具备原子性。
|
||||
也可以使用 synchronized 同步操作来保证操作具备原子性,它对应的虚拟机字节码指令为 monitorenter 和 monitorexit。
|
||||
|
||||
### 5.2 可见性
|
||||
### 2. 可见性
|
||||
|
||||
可见性是指当一个线程修改了共享变量的值,其他线程能立即得知这个修改。
|
||||
如果没有及时地对主内存与工作内存的数据进行同步,那么就会出现不一致问题。如果存在不一致的问题,一个线程对一个共享数据所做的修改就不能被另一个线程看到。
|
||||
|
||||
Java 内存模型是通过在变量修改后将新值同步回主内存,在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的,无论是普通变量还是 volatile 变量都是如此,普通变量与 volatile 变量的区别是,volatile 的特殊规则保证了新值能立即同步到主内存,以及每次使用前立即从主内存刷新。因此,可以说 volatile 保证了多线程操作时变量的可见性,而普通变量则不能保证这一点。
|
||||
volatile 可以保证可见性,它在修改一个共享数据时会将该值从工作内存同步到主内存,并且对一个共享数据进行读取时会先从主内存同步到工作内存。
|
||||
|
||||
除了 volatile 之外,Java 还有两个关键字能实现可见性,即 synchronized 和 final。同步块的可见性是由“对一个变量执行 unlock 操作之前,必须先把此变量同步回主内存中(执行 store、write 操作)”这条规则获得的,而 final 关键字的可见性是指:被 final 修饰的字段在构造器中一旦初始化完成,并且构造器没有把“this”的引用传递出去(this 引用逃逸是一件很危险的事情,其他线程有可能通过这个引用访问到“初始化了一半”的对象),那在其他线程中就能看见 final 字段的值。
|
||||
synchronized 也能够保证可见性,他能保证同一时刻只有一个线程获取锁然后执行同步代码,并且在释放锁之前会将对变量的修改刷新到主内存当中。不过只有对共享变量的 set() 和 get() 方法都加上 synchronized 才能保证可见性,如果只有 set() 方法加了 synchronized,那么 get() 方法并不能保证会从内存中读取最新的数据。
|
||||
|
||||
### 5.3 有序性
|
||||
### 3. 有序性
|
||||
|
||||
本线程内观察,所有的操作都是有序的;如果在一个线程中观察另一个线程,所有的操作都是无序的。前半句是指线程内表现为串行的语义,后半句是指指令重排和工作内存和主内存存在同步延迟的现象。
|
||||
在 Java 内存模型中,允许编译器和处理器对指令进行重排序,重排序过程不会影响到单线程程序的执行,却会影响到多线程并发执行的正确性。
|
||||
|
||||
Java 语言提供了 volatile 和 synchronized 两个关键字来保证线程之间操作的有序性,volatile 关键字本身就包含了禁止指令重排序的语义,而 synchronized 则是由“一个变量在同一个时刻只允许一条线程对其进行 lock 操作”这条规则获得的,这条规则决定了持有同一个锁的两个同步块只能串行地进入。
|
||||
volatile 关键字通过添加内存屏障的方式来禁止指令重排,即重排序时不能把后面的指令放到内存屏障之前。
|
||||
|
||||
synchronized 关键字在需要这 3 种特性的时候都可以作为其中一种的解决方案,看起来很“万能”。的确,大部分的并发控制操作都能使用 synchronized 来完成。synchronized 的“万能”也间接造就了它被程序员滥用的局面,越“万能”的并发控制,通常会伴随着越大的性能影响。
|
||||
也可以通过 synchronized 来保证有序性,它保证每个时刻只有一个线程执行同步代码,相当于是让线程顺序执行同步代码,自然就保证了有序性。
|
||||
|
||||
## 6. 先行发生原则
|
||||
## 先行发生原则
|
||||
|
||||
如果 Java 内存模型中所有的有序性都只靠 volatile 和 synchronized 来完成,那么有一些操作将会变得很繁琐,但是我们在编写 Java 并发代码的时候并没有感觉到这一点,这是因为 Java 语言中有一个“先行发生”(Happen-Before) 的原则。这个原则非常重要,它是判断数据是否存在竞争,线程是否安全的主要依据。依靠这个原则,我们可以通过几条规则一次性地解决并发环境下两个操作之间是否可能存在冲突的所有问题。
|
||||
上面提到了可以用 volatile 和 synchronized 来保证有序性。除此之外,JVM 还规定了先行发生原则,让一个操作无需控制就能先于另一个操作完成。
|
||||
|
||||
先行发生是 Java 内存模型中定义的两项操作之间的偏序关系,如果说操作 A 先行发生于操作 B,其实就是说在发生操作 B 之前,操作 A 产生的影响能被操作 B 观察到,“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等。
|
||||
主要有以下这些原则:
|
||||
|
||||
```java
|
||||
// 以下操作在线程 A 中执行
|
||||
k = 1;
|
||||
// 以下操作在线程 B 中执行
|
||||
j = k;
|
||||
// 以下操作在线程 C 中执行
|
||||
k = 2;
|
||||
```
|
||||
### 1. 单一线程原则
|
||||
|
||||
假设线程 A 中的操作“k=1”先行发生于线程 B 的操作“j=k”,那么可以确定在线程 B 的操作执行后,变量 j 的值一定等于 1,得出这个结论的依据有两个:一是根据先行发生原则,“k=1”的结果可以被观察到;二是线程 C 还没“登场”,线程 A 操作结束之后没有其他线程会修改变量 k 的值。现在再来考虑线程 C,我们依然保持线程 A 和线程 B 之间的先行发生关系,而线程 C 出现在线程 A 和线程 B 的操作之间,但是线程 C 与线程 B 没有先行发生关系,那 j 的值会是多少呢?答案是不确定!1 和 2 都有可能,因为线程 C 对变量 k 的影响可能会被线程 B 观察到,也可能不会,这时候线程 B 就存在读取到过期数据的风险,不具备多线程安全性。
|
||||
> Single thread rule
|
||||
|
||||
下面是 Java 内存模型下一些“天然的”先行发生关系,这些先行发生关系无须任何同步器协助就已经存在,可以在编码中直接使用。如果两个操作之间的关系不在此列,并且无法从下列规则推导出来的话,它们就没有顺序性保障,虚拟机可以对它们随意地进行重排序。
|
||||
在一个线程内,在程序前面的操作先行发生于后面的操作。
|
||||
|
||||
- 程序次序规则(Program Order Rule):在一个线程内,按照程序代码顺序,书写在前面的操作先行发生于书写在后面的操作。准确地说,应该是控制流顺序而不是程序代码顺序,因为要考虑分支、循环等结构。
|
||||
- 管程锁定规则(Monitor Lock Rule):一个 unlock 操作先行发生于后面对同一个锁的 lock 操作。这里必须强调的是同一个锁,而“后面”是指时间上的先后顺序。
|
||||
- volatile 变量规则(Volatile Variable Rule):对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作,这里的“后面”同样是指时间上的先后顺序。
|
||||
- 线程启动规则(Thread Start Rule):Thread 对象的 start() 方法先行发生于此线程的每一个动作。
|
||||
- 线程终止规则(Thread Termination Rule):线程中的所有操作都先行发生于对此线程的终止检测,我们可以通过 Thread.join() 方法结束、Thread.isAlive() 的返回值等手段检测到线程已经终止执行。
|
||||
- 线程中断规则(Thread Interruption Rule):对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生,可以通过 Thread.interrupted() 方法检测到是否有中断发生。
|
||||
- 对象终结规则(Finalizer Rule):一个对象的初始化完成(构造函数执行结束)先行发生于它的 finalize() 方法的开始。
|
||||
- 传递性(Transitivity):如果操作 A 先行发生于操作 B,操作 B 先行发生于操作 C,那就可以得出操作 A 先行发生于操作 C 的结论。
|
||||
<div align="center"> <img src="../pics//single-thread-rule.png"/> </div><br>
|
||||
|
||||
```java
|
||||
private int value = 0;
|
||||
pubilc void setValue(int value) {
|
||||
this.value = value;
|
||||
}
|
||||
public int getValue() {
|
||||
return value;
|
||||
}
|
||||
```
|
||||
上述代码显示的是一组再普通不过的 getter/setter 方法,假设存在线程 A 和 B,线程 A 先(时间上的先后)调用了“setValue(1)”,然后线程 B 调用了同一个对象的“getValue()”,那么线程 B 收到的返回值是什么?
|
||||
### 2. 管程锁定规则
|
||||
|
||||
我们依次分析一下先行发生原则中的各项规则,由于两个方法分别由线程 A 和线程 B 调用,不在一个线程中,所以程序次序规则在这里不适用;由于没有同步块,自然就不会发生 lock 和 unlock 操作,所以管程锁定规则不适用;由于 value 变量没有被 volatile 关键字修饰,所以 volatile 变量规则不适用;后面的线程启动、终止、中断规则和对象终结规则也和这里完全没有关系。因为没有一个适用的先行发生规则,所以最后一条传递性也无从谈起,因此我们可以判定尽管线程 A 在操作时间上先于线程 B,但是无法确定线程 B 中“getValue()”方法的返回结果,换句话说,这里面的操作不是线程安全的。
|
||||
> Monitor Lock Rule
|
||||
|
||||
那怎么修复这个问题呢?我们至少有两种比较简单的方案可以选择:要么把 getter/setter 方法都定义为 synchronized 方法,这样就可以套用管程锁定规则;要么把 value 定义为 volatile 变量,由于 setter 方法对 value 的修改不依赖 value 的原值,满足 volatile 关键字使用场景,这样就可以套用 volatile 变量规则来实现先行发生关系。
|
||||
一个 unlock 操作先行发生于后面对同一个锁的 lock 操作。
|
||||
|
||||
通过上面的例子,我们可以得出结论:一个操作“时间上的先发生”不代表这个操作会是“先行发生”,那如果一个操作“先行发生”是否就能推导出这个操作必定是“时间上的先发生”呢?很遗憾,这个推论也是不成立的,一个典型的例子就是多次提到的“指令重排序”。
|
||||
<div align="center"> <img src="../pics//monitor-lock-rule.png"/> </div><br>
|
||||
|
||||
```java
|
||||
// 以下操作在同一个线程中执行
|
||||
int i = 1;
|
||||
int j = 2;
|
||||
```
|
||||
### 3. volatile 变量规则
|
||||
|
||||
代码清单的两条赋值语句在同一个线程之中,根据程序次序规则,“int i=1”的操作先行发生于“int j=2”,但是“int j=2”的代码完全可能先被处理器执行,这并不影响先行发生原则的正确性,因为我们在这条线程之中没有办法感知到这点。
|
||||
> Volatile Variable Rule
|
||||
|
||||
上面两个例子综合起来证明了一个结论:时间先后顺序与先行发生原则之间基本没有太大的关系,所以我们衡量并发安全问题的时候不要受到时间顺序的干扰,一切必须以先行发生原则为准。
|
||||
对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作。
|
||||
|
||||
# 九、线程安全
|
||||
<div align="center"> <img src="../pics//volatile-variable-rule.png"/> </div><br>
|
||||
|
||||
### 4. 线程启动规则
|
||||
|
||||
> Thread Start Rule
|
||||
|
||||
Thread 对象的 start() 方法先行发生于此线程的每一个动作。
|
||||
|
||||
<div align="center"> <img src="../pics//thread-start-rule.png"/> </div><br>
|
||||
|
||||
### 5. 线程加入规则
|
||||
|
||||
> Thread Join Rule
|
||||
|
||||
join() 方法返回先行发生于 Thread 对象的结束。
|
||||
|
||||
<div align="center"> <img src="../pics//thread-join-rule.png"/> </div><br>
|
||||
|
||||
### 6. 线程中断规则
|
||||
|
||||
> Thread Interruption Rule
|
||||
|
||||
对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生,可以通过 Thread.interrupted() 方法检测到是否有中断发生。
|
||||
|
||||
### 7. 对象终结规则
|
||||
|
||||
> Finalizer Rule
|
||||
|
||||
一个对象的初始化完成(构造函数执行结束)先行发生于它的 finalize() 方法的开始。
|
||||
|
||||
### 8. 传递性
|
||||
|
||||
> Transitivity
|
||||
|
||||
如果操作 A 先行发生于操作 B,操作 B 先行发生于操作 C,那么操作 A 先行发生于操作 C。
|
||||
|
||||
# 八、线程安全
|
||||
|
||||
《Java Concurrency In Practice》的作者 Brian Goetz 对“线程安全”有一个比较恰当的定义:“当多个线程访问一个对象时,如果不用考虑这些线程在运行时环境下的调度和交替执行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获得正确的结果,那这个对象是线程安全的”。
|
||||
|
||||
|
@ -830,7 +786,7 @@ incrementAndGet() 方法在一个无限循环中,不断尝试将一个比当
|
|||
|
||||
Java 语言中,如果一个变量要被多线程访问,可以使用 volatile 关键字声明它为“易变的”;如果一个变量要被某个线程独享,Java 中就没有类似 C++中 \_\_declspec(thread)这样的关键字,不过还是可以通过 java.lang.ThreadLocal 类来实现线程本地存储的功能。每一个线程的 Thread 对象中都有一个 ThreadLocalMap 对象,这个对象存储了一组以 ThreadLocal.threadLocalHashCode 为键,以本地线程变量为值的 K-V 值对,ThreadLocal 对象就是当前线程的 ThreadLocalMap 的访问入口,每一个 ThreadLocal 对象都包含了一个独一无二的 threadLocalHashCode 值,使用这个值就可以在线程 K-V 值对中找回对应的本地线程变量。
|
||||
|
||||
# 十、锁优化
|
||||
# 九、锁优化
|
||||
|
||||
高效并发是从 JDK 1.5 到 JDK 1.6 的一个重要改进,HotSpot 虚拟机开发团队在这个版本上花费了大量的精力去实现各种锁优化技术,如适应性自旋(Adaptive Spinning)、锁消除(Lock Elimination)、锁粗化(Lock Coarsening)、轻量级锁(Lightweight Locking)和偏向锁(Biased Locking)等。这些技术都是为了在线程之间更高效地共享数据,以及解决竞争问题,从而提高程序的执行效率。
|
||||
|
||||
|
@ -917,7 +873,7 @@ public static String concatString(String s1, String s2, String s3) {
|
|||
|
||||
偏向锁可以提高带有同步但无竞争的程序性能。它同样是一个带有效益权衡(Trade Off)性质的优化,也就是说,它并不一定总是对程序运行有利,如果程序中大多数的锁总是被多个不同的线程访问,那偏向模式就是多余的。在具体问题具体分析的前提下,有时候使用参数 -XX:-UseBiasedLocking 来禁止偏向锁优化反而可以提升性能。
|
||||
|
||||
# 十一、多线程开发良好的实践
|
||||
# 十、多线程开发良好的实践
|
||||
|
||||
1. 给线程起个有意义的名字,这样可以方便找 Bug;
|
||||
|
||||
|
@ -935,3 +891,5 @@ public static String concatString(String s1, String s2, String s3) {
|
|||
- [Java 线程面试题 Top 50](http://www.importnew.com/12773.html)
|
||||
- [BlockingQueue](http://tutorials.jenkov.com/java-util-concurrent/blockingqueue.html)
|
||||
- [thread state java](https://stackoverflow.com/questions/11265289/thread-state-java)
|
||||
- [CSC 456 Spring 2012/ch7 MN](http://wiki.expertiza.ncsu.edu/index.php/CSC_456_Spring_2012/ch7_MN)
|
||||
- [Java - Understanding Happens-before relationship](https://www.logicbig.com/tutorials/core-java-tutorial/java-multi-threading/happens-before.html)
|
||||
|
|
|
@ -125,7 +125,7 @@ objB.instance = objA;
|
|||
|
||||
通过 GC Roots 作为起始点进行搜索,能够到达到的对象都是都是可用的,不可达的对象可被回收。
|
||||
|
||||
<div align="center"> <img src="../pics//0635cbe8.png"/> </div><br>
|
||||
<div align="center"> <img src="../pics//0635cbe8.png" width=""/> </div><br>
|
||||
|
||||
GC Roots 一般包含以下内容:
|
||||
|
||||
|
@ -620,7 +620,7 @@ public static void main(String[] args) {
|
|||
|
||||
应用程序都是由三种类加载器相互配合进行加载的,如果有必要,还可以加入自己定义的类加载器。下图展示的类加载器之间的层次关系,称为类加载器的双亲委派模型(Parents Delegation Model)。该模型要求除了顶层的启动类加载器外,其余的类加载器都应有自己的父类加载器,这里类加载器之间的父子关系一般通过组合(Composition)关系来实现,而不是通过继承(Inheritance)的关系实现。
|
||||
|
||||
<div align="center"> <img src="../pics//2cdc3ce2-fa82-4c22-baaa-000c07d10473.jpg" width=""/> </div><br>
|
||||
<div align="center"> <img src="../pics//class_loader_hierarchy.png" width="600"/> </div><br>
|
||||
|
||||
**(一)工作过程**
|
||||
|
||||
|
@ -692,3 +692,4 @@ java -Xmx12m -Xms3m -Xmn1m -XX:PermSize=20m -XX:MaxPermSize=20m -XX:+UseSerialGC
|
|||
- [Android on x86: Java Native Interface and the Android Native Development Kit](http://www.drdobbs.com/architecture-and-design/android-on-x86-java-native-interface-and/240166271)
|
||||
- [深入理解 JVM(2)——GC 算法与内存分配策略](https://crowhawk.github.io/2017/08/10/jvm_2/)
|
||||
- [深入理解 JVM(3)——7 种垃圾收集器](https://crowhawk.github.io/2017/08/15/jvm_3/)
|
||||
- [JVM Internals](http://blog.jamesdbloom.com/JVMInternals.html)
|
||||
|
|
BIN
pics/600px-Sharedmem.jpg
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
pics/class_loader_hierarchy.png
Normal file
After Width: | Height: | Size: 123 KiB |
BIN
pics/monitor-lock-rule.png
Normal file
After Width: | Height: | Size: 25 KiB |
BIN
pics/single-thread-rule.png
Normal file
After Width: | Height: | Size: 16 KiB |
BIN
pics/thread-join-rule.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
pics/thread-start-rule.png
Normal file
After Width: | Height: | Size: 23 KiB |
BIN
pics/volatile-variable-rule.png
Normal file
After Width: | Height: | Size: 30 KiB |