锁的优化及注意事项（一）

一、提高锁性能的几点建议

锁的竞争会导致程序整体性能的下降，如何降低锁竞争带来的副作用是我们必须考虑的。下面提出几点锁优化的建议：

1.1 减小锁持有时间

单个线程对锁的持有时间与系统的性能密切相关。如果线程持有锁的时间越长，那么锁的竞争程度就会越激烈。因此，应尽可能减少线程对某个锁的占有时间，进而减少线程间互斥的可能。看下面这段代码：

public synchronized void syncMethod() {
    othercode1();
    mutexMethod();
    othercode2();
}

假设只有mutexMethod()有同步需要，而othercode1()和othercode2()不需要做同步控制。如果othercode1()和othercode2()都是重量级的方法，那么就会花费较长的CPU时间。改进后的代码如下：

public void syncMethod() {
    othercode1();
    synchronized(this) {
        mutexMethod();
    }
    othercode2();
}

只对需要同步的方法进行同步控制，这样锁的占用时间会大大减少，进而提高系统的并行性能。

1.2 减小锁粒度

对于HashMap来说，最重要的两个方法就是get()和put()。一种最自然的的想法就是对整个HashMap加锁，必然可以得到一个线程安全的对象。但是这样做，我们就认为加锁粒度太大。对于ConcurrentHashMap，它内部进一步细分了若干个小的HashMap，称之为段（SEGMENT）。默认情况下，一个ConcurrentHashMap被进一步细分为16个段。

如果需要在ConcurrentHashMap中增加一个新的表项，并不是将整个HashMap加锁，而是首先根据hashcode得到该表项应该被存放到哪个段中，然后对该段加锁，并完成put()操作。在多线程环境中，如果多个线程同时进行put()操作，只要被加入的表项不存放在同一个段中，则线程间便可以做到真正的并行。下面代码展示了put()操作的过程：

public V put(K key, V value) {
    Segment<K,V> s;
    if (value == null)
        throw new NullPointerException();
    //获取段的序号
    int hash = hash(key);
    int j = (hash >>> segmentShift) & segmentMask;
    if ((s = (Segment<K,V>)UNSAFE.getObject // nonvolatile; recheck
      (segments, (j << SSHIFT) + SBASE)) == null) // in ensureSegment
        //得到段
        s = ensureSegment(j);
    return s.put(key, hash, value, false);
}

但是这样会存在一个问题：当系统需要取得全局锁时，其消耗的资源会比较多。仍然以ConcurrentHashMap类为例，虽然其put()方法很好地分离了锁，但是当试图访问ConcurrentHashMap全局信息时，就会需要同时取得所有段的锁方能顺利实施。比如ConcurrentHashMap的size()方法，它将返回ConcurrentHashMap的有效表项的数量，即ConcurrentHashMap的全部有效表项之和。要获得这个信息需要取得所有子段的锁。下面是size()方法的部分代码：

sum = 0;
for(int i=0; i<segments.length; ++i)
    segments[i].lock();
for(int i=0; i<segments.length; ++i)
    sum += segments[i].count;
for(int i=0; i<segments.length; ++i)
    segments[i].unlock();

可以看到在计算总数时，先要获得所有段的锁，然后再求和。但是，ConcurrentHashMap的size()方法并不总是这样执行，事实上，size()方法会先使用无锁的方式求和，如果失败才会尝试这种加锁的方法。

1.3 读写分离锁来替换独占锁

在读多写少的场合，读写锁对系统性能是很有好处的。因为如果系统在读写数据时均使用独占锁，那么读操作和写操作间、读操作和读操作间、写操作和写操作间均不能做到真正的并发，并且需要相互等待。而读操作本身不会影响数据的完整性和一致性。因此，理论上，在大部分情况下，应该可以允许多线程同时读，读写锁正是实现了这种功能。

1.4 锁分离

锁分离是读写锁的而进一步延伸。 一个典型的案例就是java.util.concurrent.LinkedBlockingQueue的实现。
在LinkedBlockingQueue的实现中，take()函数和put()函数分别实现了从队列中取得数据和往队列中增加数据的功能。虽然两个函数都对当前队列进行了修改操作，但由于LinkedBlockingQueue是基于链表的，因此，两个操作分别作用于队列的前端和尾端，从理论上说，并不冲突。

如果使用独占锁，则要求在两个操作进行时获取当前队列的独占锁，那么take()和put()操作就不可能真正的并发，在运行时，它们会彼此等待对方释放锁资源。在这种情况下，锁竞争会相对比较激烈，从而影响程序在高并发时的性能。因此，在JDK的实现中，并没有采用这样的方式，取而代之的是两把不同的锁，分离了take()和put()操作。

/** Lock held by take, poll, etc */
private final ReentrantLock takeLock = new ReentrantLock();

/** Wait queue for waiting takes */
private final Condition notEmpty = takeLock.newCondition();

/** Lock held by put, offer, etc */
private final ReentrantLock putLock = new ReentrantLock();

/** Wait queue for waiting puts */
private final Condition notFull = putLock.newCondition();

take()与put()函数相互独立，不存在锁的竞争关系。只需要在take()和take()间、put()和put()间分别对takeLock和putLock进行竞争。从而，削弱了锁竞争的可能性。
函数take()的实现如下：

public E take() throws InterruptedException {
    E x;
    int c = -1;
    final AtomicInteger count = this.count;
    final ReentrantLock takeLock = this.takeLock;
    takeLock.lockInterruptibly(); //不能有两个线程同时取数据
    try {
        while (count.get() == 0) { //如果当前没有可用数据，一直等待
            notEmpty.await(); //等待，put()操作的通知
        }
        x = dequeue(); //取得第一个数据
        c = count.getAndDecrement(); //数量减1，原子操作
        if (c > 1)
            notEmpty.signal(); //通知其他take()操作
        } finally {
            takeLock.unlock(); //释放锁
        }
    if (c == capacity)
        signalNotFull(); //通知put()操作，已有空余空间
    return x;
}

函数put()的实现如下:

public void put(E e) throws InterruptedException {
    if (e == null) throw new NullPointerException();
    int c = -1;
    Node<E> node = new Node(e);
    final ReentrantLock putLock = this.putLock;
    final AtomicInteger count = this.count;
    putLock.lockInterruptibly(); //不能有两个线程同时进行put()
    try {
        while (count.get() == capacity) { //如果队列已经满了
            notFull.await(); //等待
        }
        enqueue(node); //插入数据
        c = count.getAndIncrement(); //更新总数，变量c是count加1前的值
        if (c + 1 < capacity)
            notFull.signal(); //有足够的空间，通知其他线程
    } finally {
        putLock.unlock(); //释放锁
    }
    if (c == 0)
    signalNotEmpty(); //插入成功后，通知take()操作取数据
}

1.5 锁粗化

通常情况下，为了保证多线程间的有效并发，会要求每个线程持有锁的时间尽量短，即在使用完公共资源后，应该立即释放锁。只有这样，等待在这个锁上的其他线程才能尽早地获得资源执行任务。但是，如果对同一个锁不停地进行请求、同步和释放，其本身也会消耗系统宝贵的资源，反而不利于性能的优化。

为此，虚拟机在遇到一连串连读地对同一锁不断进行请求和释放的操作时，便会把所有的锁作整合成对锁的一次请求，从而减少对锁的请求同步次数，这个操作叫做锁是粗化。比如代码段：

public void demoMethod() {
    synchronized(lock) {
        //do sth
    }
    //做其他不需要的同步的工作，但能很快执行完毕
    synchronized(lock) {
        //do sth
    }
}

按照锁粗化的思想，整合后代码如下：

public void demoMethod() {
    synchronized(lock) {
        //do sth
        //做其他不需要的同步的工作，但能很快执行完毕
    }
}

二、Java虚拟机对锁优化所做的努力

2.1 偏向锁

偏向锁的核心思想是：如果一个线程获得了锁，那么锁就进入了偏向模式。当这个线程再次请求锁的时候无需再去做任何同步操作，节省了锁的申请操作，提高程序的性能。偏向锁不适合锁竞争激烈的情况。使用Java虚拟机参数-XX:UseBiasedLocking可以开启偏向锁。

2.2 轻量级锁

如果偏向锁失败，虚拟机并不会立即挂起线程。它还会使用一种称为轻量级锁的优化手段。轻量级锁的操作也很轻便，它只是简单地将对象头部作为指针，指向持有锁的线程堆栈的内部，来判断一个线程是否持有对象锁。如果线程获得轻量级锁成功，则可以顺利进入临界区。如果轻量级锁加锁失败，则表示其他线程抢先争夺到了锁，那么当前线程的锁请求就会膨胀为重量级锁。

2.3 自旋锁

锁膨胀后，虚拟机为了避免线程真实地在操作系统层面挂起，虚拟机还会在做最后的努力–自旋锁。由于当前线程暂时无法获得锁，但是什么时候可以获得锁是一个未知数。也许在几个CPU时钟周期后，就可以得到锁。如果这样，简单粗暴地挂起线程可能是一种得不偿失的操作。因此，系统会进行一次赌注：它会假设在不久的将来，线程可以得到这把锁。因此，虚拟机会让当前线程做几个空循环，在经过若干次循环后，如果可以得到锁，那么就顺利进入临界区。如果还不能得到锁，才会真实地将线程在操作系统层面挂起。

2.4 锁清除

锁消除是一种更彻底的锁优化。Java虚拟机在JIT编译时，通过对上下文的扫描，去除不可能存在共享资源竞争的锁。通过锁消除，可以节省毫无意义的请求锁时间。
例如，在一个不可能存在并发竞争的场合使用Vector，而Vector内部使用了Synchronized请求锁。比如下面的代码：

public String[] createStrings() {
    Vector<String> v = new Vector<String>();
    for(int i=0; i<100; i++) {
        v.add(Integer.toString(i));
    }
    return v.toArray(new String[]{});
}

v属于线程私有数据，不可能被其它线程访问。这种情况下，Vector内部所有加锁同步都是没有必要的，虚拟机检测到这种情况就会将这些无用的锁清除掉。

三、ThreadLocal

ThreadLocal是一个本地线程副本变量工具类。主要用于将私有线程和该线程存放的副本对象做一个映射，各个线程之间的变量互不干扰，在高并发场景下，可以实现无状态的调用，特别适用于各个线程依赖不通的变量值完成操作的场景。

3.1 ThreadLocal实现原理

• 每个Thread线程内部都有一个Map;
• Map里面存储线程本地对象（key）和线程的变量副本（value）
• Thread内部的Map是由ThreadLocal维护的，由ThreadLocal负责向map获取和设置线程的变量值。

所以对于不同的线程，每次获取副本值时，别的线程并不能获取到当前线程的副本值，形成了副本的隔离，互不干扰。

Thread线程内部的Map在类中描述如下：

public class Thread implements Runnable {
    /* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
    ThreadLocal.ThreadLocalMap threadLocals = null;
}

ThreadLocal如何保证这些对象只被当前线程所访问，我们需要关注的是ThreadLocal的set()方法和get()方法。

1. get()方法

get()方法用于获取当前线程的副本变量值。

  public T get() {
      Thread t = Thread.currentThread();
      ThreadLocalMap map = getMap(t);
      if (map != null) {
          ThreadLocalMap.Entry e = map.getEntry(this);
          if (e != null)
              return (T)e.value;
      }
      return setInitialValue();
  }

  ThreadLocalMap getMap(Thread t) {
      return t.threadLocals;
  }

  private T setInitialValue() {
      T value = initialValue();
      Thread t = Thread.currentThread();
      ThreadLocalMap map = getMap(t);
      if (map != null)
          map.set(this, value);
      else
          createMap(t, value);
      return value;
  }

  protected T initialValue() {
      return null;
  }

get()方法是先取得当前线程的ThreadLocalMap对象。然后，通过将自己作为key取得内部的实际数据。

2. set()方法

set()方法用于保存当前线程的副本变量值。

  public void set(T value) {
      Thread t = Thread.currentThread();
      ThreadLocalMap map = getMap(t);
      if (map != null)
          map.set(this, value);
      else
          createMap(t, value);
  }

  ThreadLocalMap getMap(Thread t) {
      return t.threadLocals;
  }

  void createMap(Thread t, T firstValue) {
      t.threadLocals = new ThreadLocalMap(this, firstValue);
  }
  ```
  在set时，首先获得当前线程对象，然后通过getMap()拿到线程的ThreadLocalMap，并将值设入ThreadLocalMap中。

当线程退出时，Thread类会进行一些清理工作，其中就包括清理ThreadLocalMap：
```java
private void exit() {
        if (group != null) {
            group.threadTerminated(this);
            group = null;
        }
        /* Aggressively null out all reference fields: see bug 4006245 */
        target = null;
        /* Speed the release of some of these resources */
        threadLocals = null;
        inheritableThreadLocals = null;
        inheritedAccessControlContext = null;
        blocker = null;
        uncaughtExceptionHandler = null;
}

如果使用线程池，意味着当前线程未必会退出（比如固定大小的线程池，线程总是存在）如果这样，将一些大大的对象设置到ThreadLocal中（它实际保存在线程持有的threadLocals Map内），可能会使系统出现内存泄漏的可能。此时，如果希望及时回收对象，最好使用ThreadLocal.remove()方法将整个变量移除。

既然Key是弱引用，那么我们要做的事，就是在调用ThreadLocal的get()、set()方法时完成后再调用remove方法，将Entry节点和Map的引用关系移除，这样整个Entry对象在GC Roots分析后就变成不可达了，下次GC的时候就可以被回收。如果使用ThreadLocal的set方法之后，没有显示的调用remove方法，就有可能发生内存泄露，所以养成良好的编程习惯十分重要，使用完ThreadLocal之后，记得调用remove方法。