锁优化角度
减小锁持有的时间
在真正需要同步的代码块进行加锁，避免在整个任务的处理上加锁，有助于降低锁冲突的可能性，进而提升系统的并发能力。
减小锁粒度
缩小锁定对象的范围，降低锁冲突可能性，进而提升系统并发能力。例如 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 值。
