synchronized不能锁静态变量_你用对锁了吗？浅谈 Java “锁” 事

并发 BUG 的源头

我们知道电脑有CPU、内存、硬盘，硬盘的读取速度最慢，其次是内存的读取，内存的读取相对于 CPU 的运行又太慢了，因此又搞了个CPU缓存，L1、L2、L3。

正是这个CPU缓存再加上现在多核CPU的情况产生了并发BUG。

这就一个很简单的代码，如果此时有线程 A 和线程 B 分别在 CPU - A 和 CPU - B 中执行这个方法，它们的操作是先将 a 从主存取到 CPU 各自的缓存中，此时它们缓存中 a 的值都是 0。

然后它们分别执行 a++，此时它们各自眼中 a 的值都是 1，之后把 a 刷到主存的时候 a 的值还是1，这就出现问题了，明明执行了两次加一最终的结果却是 1，而不是 2。

这个问题就叫可见性问题。

在看我们 a++ 这条语句，我们现在的语言都是高级语言，这其实和语法糖很类似，用起来好像很方便实际上那只是表面，真正需要执行的指令一条都少不了。

高级语言的一条语句翻译成 CPU 指令的时候可不止一条， 就例如 a++ 转换成 CPU 指令至少就有三条。

• 把 a 从内存拿到寄存器中；
• 在寄存器中 +1；
• 将结果写入缓存或内存中；

所以我们以为 a++ 这条语句是不可能中断的是具备原子性的，而实际上 CPU 可以能执行一条指令时间片就到了，此时上下文切换到另一个线程，它也执行 a++。再次切回来的时候 a 的值其实就已经不对了。 这个问题叫做原子性问题。 并且编译器或解释器为了优化性能，可能会改变语句的执行顺序，这叫指令重排，最经典的例子莫过于单例模式的双重检查了。而 CPU 为了提高执行效率，还会乱序执行，例如 CPU 在等待内存数据加载的时候发现后面的加法指令不依赖前面指令的计算结果，因此它就先执行了这条加法指令。 这个问题就叫有序性问题。 至此已经分析完了并发 BUG 的源头，即这三大问题。可以看到不管是 CPU 缓存、多核 CPU 、高级语言还是乱序重排其实都是必要的存在，所以我们只能直面这些问题。 而解决这些问题就是通过禁用缓存、禁止编译器指令重排、互斥等手段，今天我们的主题和互斥相关。 互斥就是保证对共享变量的修改是互斥的，即同一时刻只有一个线程在执行。而说到互斥相信大家脑海中浮现的就是 锁。没错，我们今天的主题就是锁！锁就是为了解决原子性问题。

 

锁

说到锁可能 Java 的同学第一反应就是 synchronized 关键字，毕竟是语言层面支持的。我们就先来看看 synchronized，有些同学对 synchronized 理解不到位所以用起来会有很多坑。

 

synchronized 注意点

我们先来看一份代码，这段代码就是咱们的涨工资之路，最终百万是洒洒水的。而一个线程时刻的对比着我们工资是不是相等的。我简单说一下 IntStream.rangeClosed(1,1000000).forEach ，可能有些人对这个不太熟悉，这个代码的就等于 for 循环了100W次。

你先自己理解下，看看觉得有没有什么问题？第一反应好像没问题，你看着涨工资就一个线程执行着，这比工资也没有修改值，看起来好像没啥毛病？没有啥并发资源的竞争，也用 volatile 修饰了保证了可见性。 让我们来看一下结果，我截取了一部分。