锁优化角度
减小锁持有的时间
在真正需要同步的代码块进行加锁,避免在整个任务的处理上加锁,有助于降低锁冲突的可能性,进而提升系统的并发能力。
减小锁粒度
缩小锁定对象的范围,降低锁冲突可能性,进而提升系统并发能力。例如 ConcurrentHashMap
内部细分为若干个小的 HashMap
,添加数据时可能只需要对其中的某个 SEGMENT
加锁,这样同时就有多个线程可以操作 ConcurrentHashMap
,大大提高了吞吐量。
使用读写锁代替独占锁
理论上读-读之前是不应该阻塞的,在读多写少的情况下,使用读写锁相对于独占锁能够有效提升系统并发能力。
锁分离
在区别读写锁的基础上进一步延伸,就是锁分离。例如如果需要创建一个线程安全的容器,其加入元素和弹出元素的操作必须要获得容器的锁,那么在运行时,加入和弹出操作就必须等待对方释放资源,如果锁竞争激烈,并发性能就会大大下降。而 LinkedBlockingQueue
的实现中,则使用了读锁和写锁两把锁,其原理是利用 ReentrantLock
和 Condition
分别阻塞和唤醒线程,使得读取和写入之间可以并发。
锁粗化
虚拟机在一系列对同一锁不断进行请求和释放的操作时,便会把所有锁操作整合为对锁的一次请求,从而减少对锁的请求同步次数。锁粗化的思想和减少锁的持有时间是相反的。
JVM对锁的优化
偏向锁
如果某个线程获取了锁,到再次请求锁时,没有其他线程再去请求该锁,则省略线程申请锁的同步操作。在几乎没有锁竞争的场合中,偏向锁具有很强的优化效果;但在锁竞争激烈的情况下,可能是多个线程请求相同的锁,偏向模式就会失效。通过虚拟机参数 -XX:+UseBiasedLocking
开启偏向锁。
轻量级锁
线程在执行同步块之前,JVM会先在当前线程的栈桢中创建用于存储锁记录的空间,并将对象头中的 Mark Word
复制到锁记录中,然后线程尝试使用 CAS
将对象头中的 Mark Word
替换为指向锁记录的指针。如果成功则线程可以顺利进入临界区,如果失败,锁请求会膨胀为重量级锁。
自旋锁
假设在不久的将来,线程就可以获取请求的锁资源,那么直接在操作系统层面将线程挂起是得不偿失的,因此虚拟机会让当前线程做几个空循环,如果若干次循环后能够获得锁,则顺利进入临界区,否则才会将线程真实地在操作系统层面挂起。
锁消除
虚拟机在 JIT
编译时通过对上下文的扫描,能够去除不可能存在共享资源竞争的锁。通过锁消除,可以节省无意义的请求锁的时间。锁消除设计的一项关键技术为逃逸分析,即观察某一个变量是否会逃出某一个作用域。
ThreadLocal
ThreadLocal
表示线程局部变量,只有当前线程才能访问,因此是线程安全的,但是不同线程的 ThreadLocal
如果存放了相同的对象,那么也是线程不安全的,需要在应用层作出保证。如果共享对象对于竞争的处理容易造成性能损失,则应该考虑使用 ThreadLocal
为每个线程分配单独的对象。
ThreadLocal.set(T value)
在调用 ThreadLocal
的 set()
方法时,先根据当前线程获取 ThreadLocal.ThreadLocalMap
的一个实例(可以理解为一个Map),写入数据时,以 ThreadLocal
对象作为 key
,写入的数据作为 value
。
ThreadLocal.get()
在调用 ThreadLocal
的 get()
方法时,获取当前线程对应的 ThreadLocal.ThreadLocalMap
实例,再使用 ThreadLocal
对象作为 key
取出数据。
ThreadLocal.remove()
通过 ThreadLocal
写入的数据是维护在线程内部的,所以只要线程不退出,对象引用就会一直存在。如果使用线程池,在任务结束后不对数据进行清理,则可能会造成内存泄漏,因此在数据使用完成后最好使用 ThreadLocal.remove()
将数据移除。
无锁
对于并发而言,锁是一种悲观的策略,它总是假设每次临界区操作都会产生冲突,在获取不到锁时,会阻塞线程执行。而无锁是一种乐观的策略,它假设对资源的访问是没有冲突的,所有线程都可以在非阻塞的情况下执行,无锁策略使用 CAS (Compare And Swap)
来鉴别线程冲突,一旦检测到冲突,就重试当前操作至没有冲突为止。
CAS
CAS (Compare And Swap,比较交换)
由于其非阻塞性,对死锁问题天生免疫;线程间的相互影响远比基于锁的方式要小;使用无锁的方式完全没有锁竞争和线程间频繁调度带来的系统开销,因此无锁比基于锁的方式拥有更优越的性能。
CAS算法
CAS(V, E, N)
包含3个参数:
-
V
:要更新的变量的值。 -
E
:变量的预期值。 -
N
:变量需要更新的值。
CAS
是一个原子操作,仅当 V
和 E
相等时,才会将变量的值更新为 N
,否则说明有其它线程对这个变量做了修改操作,当前线程放弃更新,最后返回变量的真实值。
CAS核心操作
以 AtomicInteger
为例,此类中的核心字段为:
// 实际取值
private volatile int value;
incrementAndGet()
方法的作用是自增1并获取变量的值,其内部调用的是 Unsafe
类的 getAndAddInt()
方法。
public final int incrementAndGet() {
return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}
/**
* @param obj 进行修改的AtomicInteger对象
* @param valueOffset AtomicInteger的value字段的地址偏移量
* @param i 要增加的数值
* @return 被修改的变量修改前的值
*/
public final int getAndAddInt(Object obj, long valueOffset, int i) {
int pre;
do {
// 需要修改的变量的当前值
pre = this.getIntVolatile(obj, valueOffset);
// CAS操作,成功返回true,失败返回false
} while(!this.compareAndSwapInt(obj, valueOffset, pre, pre + i));
return pre;
}
getAndAddInt()
方法被调用后,循环调用Java Native 方法 compareAndSwapInt()
,如果修改成功则退出循环,返回被修改的变量修改前的值,如果修改不成功,则会一直重试直至成功修改。
ABA问题
从内存中读取和比较之间,变量的值可能被多次修改,最终回到原来的值,当前线程可能就会误以为此变量未修改。为了解决这类问题,可以引入 AtomicStampedReference
,它的内部不仅维护了变量的值,还维护了修改的时间戳(或者可以看作是版本号),当进行 CAS
操作时,对象值和时间戳都满足期望值,修改才会成功。
普通字段的原子操作
原子包提供 AtomicIntegerFieldUpdater
,AtomicReferenceFieldUpdater
等工具用于给普通资源提供原子操作,其使用方式如下:
T t = new T();
AtomicIntegerFieldUpdater<T> number = AtomicIntegerFieldUpdater.newUpdater(T.class, "number");
number.incrementAndGet(t);
使用这些工具需要注意:
- 只能增强非
private
字段,即只能修改可见范围内的字段。 - 被增强的字段必须要用
volatile
字段修饰,用于确保变量被正确的读取。 - 由于
CAS
会通过对象实例中的偏移量直接进行赋值,所以增强不支持static
字段。
Unsafe类
sun.misc.Unsafe
类封装了一些不安全的操作,主要是为了操作指针,例如:
public native int getInt(Object obj, long offset);
此方法的作用是获取到对象 obj
头部的偏移量为 offset
的 int
值。
网友评论