- 提高锁性能的几点建议
- 减小锁持有时间
- 减小锁粒度
- 读写分离锁替换独占锁（读多写少的场景）
- 锁分离（
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章 锁的优化及注意事项
©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。
