竞争锁是造成多线程应用程序性能瓶颈的主要原因

        区分竞争锁和非竞争锁对性能的影响非常重要。如果一个锁自始至终只被一个线程使用，那么 JVM 有能力优化它带来的绝大部分损耗。如果一个锁被多个线程使用过，但是在任意时刻，都只有一个线程尝试获取锁，那么它的开销要大一些。我们将以上两种锁称为非竞争锁。而对性能影响最严重的情况出现在多个线程同时尝试获取锁时。这种情况是 JVM 无法优化的，而且通常会发生从用户态到内核态的切换。现代 JVM 已对非竞争锁做了很多优化，使它几乎不会对性能造成影响。常见的优化有以下几种。

        * 如果一个锁对象只能由当前线程访问，那么其他线程无法获得该锁并发生同步 , 因此 JVM 可以去除对这个锁的请求。
        * 逸出分析 (escape analysis) 可以识别本地对象的引用是否在堆中被暴露。如果没有，就可以将本地对象的引用变为线程本地的 (thread local) 。
        * 编译器还可以进行锁的粗化 (lock coarsening) 。把邻近的 synchronized 块用相同的锁合并起来，以减少不必要的锁的获取和释放。

        因此，不要过分担心非竞争锁带来的开销，要关注那些真正发生了锁竞争的临界区中性能的优化。

        降低锁竞争的方法

        很多开发人员因为担心同步带来的性能损失，而尽量减少锁的使用，甚至对某些看似发生错误概率极低的临界区不使用锁保护。这样做往往不会带来性能提高，还会引入难以调试的错误。因为这些错误通常发生的概率极低，而且难以重现。

        因此，在保证程序正确性的前提下，解决同步带来的性能损失的第一步不是去除锁，而是降低锁的竞争。通常，有以下三类方法可以降低锁的竞争：减少持有锁的时间，降低请求锁的频率，或者用其他协调机制取代独占锁。这三类方法中包含许多最佳实践，在下文中将一一介绍。

避免在临界区中进行耗时计算

        通常使代码变成线程安全的技术是给整个函数加上一把“大锁”。例如在 Java 中，将整个方法声明为 synchronized 。但是，我们需要保护的仅仅是对象的共享状态，而不是代码。

        过长时间的持有锁会限制应用程序的可扩展性。 Brian Goetz 在《 Java Concurrency in Practice 》一书中提到，如果一个操作持有锁的时间超过 2 毫秒，并且每一个操作都需要这个锁，那么无论有多少个空闲处理器，应用程序的吞吐量都不会超过每秒 500 个操作。如果能够减少持有这个锁的时间到 1 毫秒，就能将这个与锁相关的吞吐量提高到每秒 1000 个操作。事实上，这里保守地估计了过长时间持有锁的开销，因为它并没有计算锁的竞争带来的开销。例如，因为获取锁失败带来的忙等和线程切换，都会浪费 CPU 时间。减小锁竞争发生可能性的最有效方式是尽可能缩短持有锁的时间。这可以通过把不需要用锁保护的代码移出同步块来实现， 尤其是那些花费“昂贵”的操作，以及那些潜在的阻塞操作，比如 I/O 操作。

        在例 1 中，我们使用 JLM(Java Lock Monitor) 查看 Java 中锁使用的情况。 foo1 使用 synchronized 保护整个函数，foo2 仅保护变量 maph 。 AVER_HTM 显示了每个锁的持有时间。可以看到将无关语句移出同步块后，锁的持有时间降低了，并且程序执行时间也缩短了。