Java虚拟机那些事儿，聊聊怎么让并发跑得更溜一点

开始）

聊到Java虚拟机（JVM）怎么让并发编程跑得更快，这事儿其实挺有意思的，它不是变魔术，而是JVM在背后默默地干了很多“脏活累活”，我们写的代码就像是给JVM下的指令，它怎么执行，直接决定了我们程序的效率，今天就不扯那些让人头疼的专业术语，用大白话聊聊JVM在并发这块儿是怎么“使劲”的。

咱们得明白一个核心矛盾：内存的速度和CPU的速度差得太远了，CPU干活飞快，但去内存里取个数据就像是从北京到天津跑个来回，太慢了，为了解决这个问题，CPU自己带了小块的高速缓存，叫CPU缓存，程序运行时，数据会从主内存拷贝一份到CPU的缓存里，CPU就直接在缓存里操作数据，快多了。

但这下就引出并发编程的第一个大麻烦：缓存不一致问题，想象一下，线程A跑在CPU核心1上，把共享变量X从0改成1，这个1暂时只写在了核心1的缓存里，还没同步回主内存，这时候线程B跑在CPU核心2上，它去读变量X，从主内存读到的还是旧值0，这就出错了，感觉就像是线程A的修改“丢了”，线程B看到了一个过时的世界。

JVM怎么解决这个“看到的世界不一样”的问题呢？它依赖于底层CPU提供的一套指令，也就是我们常听说的内存屏障，你可以把内存屏障理解成一道“关卡”或者“栅栏”，JVM在编译我们写的synchronized关键字或者volatile变量时，会在生成的机器指令里插入这些“关卡”，它的作用就两条：一是让关卡前的所有写操作必须“刷”回主内存，让其他CPU都能看见；二是让关卡后的读操作必须从主内存重新读取最新值，这样，就强制保证了不同线程之间对数据修改的可见性，比如你给一个变量加了volatile关键字，JVM就会在写这个变量之后加入一个“写屏障”，在读这个变量之前加入一个“读屏障”，相当于给这个变量的读写操作加了“同步”的buff。

解决了“看得见”的问题，接下来是“原子性”问题，什么叫原子性？就是说一个操作要么完全执行，要么完全不执行，中间不能被打断，比如最简单的i++，它看起来是一句，但实际上包含了“读i的值、给i加1、写回i”三个步骤，如果两个线程同时执行i++，可能就会发生“覆盖”，导致结果不是预期的2，而是1。

对付这个问题,JVM提供了最经典的武器——synchronized关键字，synchronized就像是给一段代码或者一个对象加了一把“独占锁”，线程想执行这段代码，必须先拿到这把锁，如果锁被别的线程拿走了，它就得老老实实等着（这个过程叫“阻塞”），这样，就保证了同一时间只有一个线程能执行这段代码，i++的三个步骤就能作为一个整体不可分割地完成，从而保证了原子性，虽然synchronized在早期版本性能开销比较大，但经过JVM这么多年的优化（比如锁升级），在常见场景下已经很快了，它是保证线程安全最直接、最省心的工具之一。

除了synchronized,JVM还支持基于CAS（比较并交换） 的无锁算法，CAS是CPU提供的一个原子指令，它的操作逻辑是：“我认为现在变量V的值应该是A，如果是的话，我就把它改成B；如果不是，说明有别的线程改过它了，那我就不改了，操作失败，我重试。”Java并发包里的AtomicInteger等原子类，就是靠CAS实现的，它的好处是避免了线程的挂起和唤醒（也就是阻塞），在高并发且竞争不激烈的场景下，性能比synchronized更好，你可以把它想象成一种乐观锁，它假设冲突不常发生，先干了再说，发现冲突了就重试。

JVM自身还有一个非常重要的优化机制,叫做锁升级，JVM并不是一上来就用重量级的、会导致线程阻塞的锁，它很聪明，会根据竞争情况动态调整，最开始，锁是“偏向锁”，意思是假设大多数情况下没竞争，干脆把锁“偏心”地给第一个访问它的线程，连CAS操作都省了，如果后来有第二个线程来竞争，偏向锁就升级为“轻量级锁”，这时候线程会通过CAS自旋一小段时间来尝试获取锁，避免直接进入阻塞，如果自旋了一会儿还拿不到锁，说明竞争挺激烈的，才会升级为真正的“重量级锁”，让没拿到锁的线程进入阻塞状态，这个过程就像调解矛盾，先劝和（偏向锁），劝不动就让他们自己稍微争一下（轻量级锁），实在争得不可开交了再强制管理（重量级锁），这个优化策略使得在无竞争或低竞争的场景下，加锁的开销非常小。

JVM为了让并发跑得更“溜”，主要从三个方面下功夫：一是通过内存屏障（配合volatile等）解决可见性问题，确保一个线程的修改能被其他线程看到；二是通过锁（synchronized）和原子指令（CAS）解决原子性问题，保证关键操作不被打断；三是通过锁升级等运行时优化，智能地降低同步带来的开销，理解JVM在背后做的这些努力，能帮助我们更好地理解并发编程的本质，写出更高效、更可靠的程序。 结束）