第4章锁的优化及注意事项

提高锁性能的几点建议
- 减小锁持有时间
- 减小锁粒度
- 读写分离锁替换独占锁（读多写少的场景）
- 锁分离（LinkedBlockingQueue中的putLock，takeLock）
- 锁粗化（适当扩大锁范围，尝试将多次锁操作合并）
Java 虚拟机对锁优化所做的努力
- 锁偏向，获得锁后就进入偏向模式，再次请求锁时无需任何同步操作，节省大量有关锁申请的操作，适用于几乎没有锁竞争的场合，-XX:+UseBiasedLocking可以开启偏向锁
- 轻量级锁。。。
- 自旋锁，请求锁失败时，为避免直接在操作系统层面挂起，让当前线程做几个空循环，如果依然无法获取才挂起
- 锁消除，jit编译时进行上下文扫描去除不可能存在资源竞争的锁，逃逸分析是观察某个变量是否会跳出某个作用域，在-server模式下，可以使用-XX:+DoEscapeAnalysis打开逃逸分析。使用-XX:+EliminateLocks可以打开锁消除
ThreadLocal是线程局部变量，只有当前线程可以访问，在Thread对象中持有一个ThreadLocalMap对象，在线程池的场景下，最好使用ThreadLocal.remove()将变量移除，或设为null来防止内存泄露，在一些场景下，比如多线程产生随机数使用ThreadLocal<Random>会获得更好的性能
CAS(Compare And Swap)对死锁天生免疫，线程间的相互影响也远小于基于锁的方式，没有锁竞争带来的系统开销，也咩有线程间频繁调度带来的开销，比基于锁的方式有更优越的性能。CAS(V,E,N)中V标识要更新的变量，E表示预期值，N表示新值。仅当V等于E时，才将V设为N，如果V和E不同，则说明其他线程做了更新，当前线程什么都不做，最后，CAS返回当前V的真实值。多个线程同时使用 CAS 操作一个变量时只有一个会胜出，失败的线程不会被挂起，而是进行失败重试
JDK 中的 atomic 包中实现了一些可直接使用 CAS 操作的线程安全类型，unsafe 中封装了一些和指针相关的操作，属于 JDK 内部使用的专属类。AtomicXXX 类中大量使用了 unsafe 操作
- AtomicInteger、AtomicLong等对数值封装
- AtomicReference无锁对象的引用，保证修改对象引用时的线程安全性，但存在的一个问题是只根据对象值，无法根据对象状态，即对象被修改了很多次后值和 CAS 期望值一致
- AtomicStampedReference维护了对象值和时间戳，更新时对象值和时间戳必须都满足期望值，并且会更新对象值和时间戳
- AtomicIntegerArray、AtomicLongArray、AtomicReferenceArray以AtomicIntegerArray来说，本质上是对int[]的封装，使用Unsafe类的 CAS 方式控制int[]
- AtomicIntegerFieldUpdater,AtomicLongFieldUpdater,AtomicReferenceFieldUpdater可以为对象的非private的volatile成员变量提供线程安全的更新操作

第4章 锁的优化及注意事项

推荐阅读更多精彩内容

第4章锁的优化及注意事项