Java项目性能瓶颈分析及定位（八）——Java线程堆栈分析（五）

对于CPU而言，常见的瓶颈主要有两种：
服务器的压力很小，但是CPU的利用率却很高，这样的性能瓶颈相对比较容易定位（好比我只是说了你一句，你就哭了，你的弱点立马就暴露出来了）；
给服务器施加的压力很大，但是CPU的利用率总是很低，也就是压力上不去，这类瓶颈最常见，定位起来也最困难（类似我对你用尽了各种手段，你就是不说实话，内心太强大了）。
影响压力上不去的因素很多，但是对于性能测试工程师而言，最具价值的瓶颈肯定是由于代码问题引起的了（定位到是代码问题导致的压力上不去，特有成就感），而导致这类问题出现的最常见的一个知识点，肯定就是锁了，如果对于Java多线程的锁机制不甚了解，分析定位代码的瓶颈和性能调优几乎是不可能的。
锁——确保多线程访问的数据一致性。
目前Java多线程的锁基本就是通过如下两种方式实现：
synchronized关键字
java.util.concurrent.locks包下的类（用的也蛮多，稍微有点复杂，课堂上讲吧）
今天就为大家分享synchronized关键字实现的加锁方式。
认识synchronized
假设这样一个场景，张三和李四都需要维修各自的电脑，但是只有一把螺丝刀工具，意味着同一时刻只能有一个人使用这把工具修他们的电脑，那么使用Java代码该如何实现呢？我们把张三和李四比喻成两个线程，把他们修电脑的过程用Java语言实现一下，开始！

上面代码执行后对线程做dump，摘取部分信息如下：

解读锁
wait()和sleep()
它们有一个共同点是，都会把当前的线程阻塞住（ 时长为函数参数指定的时间）， 我们称之为睡眠或者等待。但二者实际上是完全不同的两个函数， 二者有着最为本质的区别：
wait()  当线程执行到wait()方法上， 当前线程会释放监视锁， 此时其它线程可以占有该锁，一旦wait()方法执行完成， 当前线程又继续尝试获取该锁， 直到执行完该锁的作用域。 可以说wait()是多线程场合下用得最多的一个方法。 结合notify(),可以实现两个线程之间的通信,一个线程可以通过这种方法通知另一个线程继续执行， 完成线程之间的配合。 wait()和锁的示意图如下:

在wait(5000)这5秒（ 5000毫秒） 期间， 当前线程会释放它占有的锁， 此时其它线程有机会获得该锁。 当wait(5000)执行完成后， 当前线程继续获得该锁的使用权。 满足如下条件之一， wait()方法退出：
达到了等待的时间之后， 自动退出。 如wait(5000),5秒后wait方法退出。
其它的线程调用了该锁的notify()方法。 如果多个线程在等待同一个锁， 只有一个线程会被通知到。
sleep()  与锁操作无关， 如果该方法恰好在一个锁的保护范围之内， 当前线程即使在执行sleep()的时候， 仍然继续保持监视锁。 该方法实际上仅仅是完成等待或者睡眠的语义。 示意图如下：

从上面的代码Thread.sleep(5000)可以看出， sleep()方法并不是锁上面的一个方法， 而是线程的一个静态方法。 也就是说该方法实际上是和锁操作无关的。 如果sleep()方法恰好在一个锁的保护范围之内， 那么当前线程即使执行到该sleep方法， 也不会产生特别的锁操作(持有锁或者释放锁)， 如果原来持有， 现在仍然持有。 如果原来没有持有， 那么现在仍然不持有。
还记得第六篇文章解读的线程堆栈吗？包含的直接信息有：
线程的个数、 每个线程调用的方法堆栈、 当前锁的状态。 线程的个数可以直接数出来； 线程调用的方法堆栈， 从下向上看，即表示当前的线程调用了哪个类上的哪个方法。 而锁的状态看起来稍微有一点技巧。 与锁相关的三个重要信息如下：
当一个线程占有一个锁的时候， 线程堆栈中会打印—locked <0x24a23208>
当一个线程正在等待其它线程释放该锁， 线程堆栈中会打印—waiting to lock <0x24a23208>
当一个线程占有一个锁， 但又执行到该锁的wait()上， 线程堆栈中首先打印locked,然后又会打印—waiting on <0x24a23208>
源码：




运行上面的程序，打印堆栈信息如下：



从上面这个例子中， 可以很清晰地看出， 在线程堆栈中与锁相关的三个最重要的特征字:locked，waiting to lock，waiting on；了解这三个特征字， 就能够对锁进行分析了。
一般情况下， 当一个(些)线程在等待一个锁时， 应该有一个线程占用这个锁， 即如果有的线程在等待一个锁， 该锁必然被另一个线程占有了， 也就是说， 从打印的堆栈中如果能看到waiting to lock <0x04d02238>,应该也应该能找到一个线程locked <0x04d02238>。