企业官网建设流程全解析

先说个我印象很深的坑。去年有一阵子，团队里一个服务压测时CPU偶尔飙到满，代码看起来平平无奇，就是多线程跑一个统计任务。排查了半天，才发现问题不在业务逻辑，而在并发修改共享变量时，Java内存模型没有给我兜底。那时我们天天说框架真香，JDK自动管理内存省心，可一旦要动并发，不懂JVM架构和Java内存模型，真的会原地爆炸。这篇就把JVM架构与Java内存模型串起来讲清楚，重点是用内存模型的视角看懂并发Bug，适合后端开发、中间件开发，以及所有准备改并发代码的人。

1. 运行时数据区：先把 JVM 的内存地图记熟

1.1 五块区域各管什么：别再只记住堆和栈

JVM在执行Java字节码时，会把自己管理的内存划分成几块。最容易记的方法是按用途拆：程序计数器、虚拟机栈、本地方法栈、堆、方法区。前三个是线程私有的，后两个是线程共享的。这个划分不是凭空来的，它直接决定了一个对象的生命周期归谁管：线程私有的区域随线程创建销毁，共享区域由GC统一回收。

程序计数器是所有区域里最没有存在感的一块，它只是记录当前线程执行到哪一条字节码。线程切换后，恢复执行要靠它。因为它占用的空间极小，而且不会OOM。虚拟机栈则对应一次方法调用的生命周期：每调用一个方法，就压入一个栈帧，方法返回后栈帧弹出。栈帧里放着局部变量表、操作数栈、动态链接、方法出口这些信息。我们常说的StackOverflowError，就是栈深度超过虚拟机允许的深度。

本地方法栈和虚拟机栈类似，区别在于它是给native方法用的。日常写Java几乎感知不到它，但很多高性能框架会调用底层库，出问题的时候同样要看这块。我见过一个线上栈溢出案例，看堆栈全是JNI调用，最后发现是本地方法栈配置太小。这类问题不常见，但排查思路是一样的。

1.2 堆和方法区：共享内存才是并发主战场

堆是几乎所有对象实例的分配地，也是垃圾回收的主要区域。堆内部通常又分成新生代和老年代，新生代里还可以再分Eden区和两个Survivor区。这个分代设计不是为了给并发服务，而是为了GC效率，但它会深刻影响对象分配和锁竞争的场景。比如短命的大对象如果频繁创建，会加速Young GC，间接拖慢并发吞吐。

方法区在JDK8之后被元空间取代，主要存类元信息、常量、静态变量和JIT编译产物。元空间直接使用本地内存，不再受堆大小限制。以前因为字符串常量池在永久代，经常碰到永久代OOM；换成元空间后这类问题少了很多。但静态变量依然在这里，也就是说静态字段是天然的多线程共享变量，改它们前要先想清楚并发。

把JVM内存结构放一起看，结论其实很朴素：线程私有的区域天生安全，堆和方法区是共享资源。并发Bug基本都出在共享区域上。但很多人忽略了另一个层次：Java内存模型并不是按照这些物理区域来规定可见性的，它有一套更抽象的主内存-工作内存模型。这才是并发问题的真正源头。

2. Java 内存模型：并发 Bug 的老祖宗

2.1 主内存与工作内存：JVM 内存管理的二次抽象

Java内存模型（Java Memory Model，JMM）不是一个具体的物理内存划分，而是一组规范，用来定义多线程读写共享变量的行为。它规定所有共享变量都存在于主内存中，每个线程有自己的工作内存，线程不能直接操作主内存，必须先把变量复制到工作内存，执行完再写回。

这个模型和我们前面看到的堆、栈不是一回事，不要搞混。JMM的主内存概念上可以理解为所有线程共享的内存区，对应到JVM里主要就是堆；工作内存则是对应线程私有的寄存器、缓存、栈上的一些数据。之所以不直接用堆和栈来讲可见性，是因为在CPU层面还有缓存的介入，语言规范必须给出一套与具体硬件无关的一致性协议。

这个抽象跟CPU缓存的一致性很像。你可以把主内存想象成学校公告栏，工作内存是每个人手里的笔记本。线程读写共享变量，相当于先抄到笔记本上改，过一会再贴回公告栏。如果另一个线程恰好在你贴回之前看公告栏，它看到的就是旧值。这个“过一会”在程序里没有任何保证，除非你用了同步机制。

注意，JMM并不保证工作内存什么时候同步到主内存，也不保证什么时候从主内存刷新。这句话要刻在脑子里，因为很多并发Bug的答案就在这里。

2.2 三大性质：原子性、可见性、有序性

并发Bug归纳起来，总逃不过三个词的组合：原子性、可见性、有序性。

原子性解决的是“多个线程同时改一个变量会不会串”的问题。Java里最简单的count++就不是原子的，它是一条读、一条加、一条写。两个线程同时读到2，各自加1再写回，结果可能是3而不是4。在JMM里，对共享变量的复合操作必须通过锁或原子类才能保证原子性。

可见性解决的是“改了之后别人能不能马上看到”的问题。线程A把变量写回主内存之前，线程B读到的永远是自己工作内存里的旧副本。最经典的就是用boolean stop控制子线程循环退出：主线程改成true了，子线程还在跑，因为子线程根本没看到最新值。

有序性解决的是“代码顺序会不会被编译器/CPU重排”的问题。单线程里重排不会改变语义，但多线程里两个线程各自重排后，相互观察到的顺序可能是乱的。典型例子就是双重检查锁，初始化对象的步骤被重排之后，另一个线程可能拿到一个半成品对象。

三者不是完全独立。有些技术能同时解决两个，比如volatile保证了可见性，也限制了重排，但不保证原子性；synchronized则三者都能保证，代价是让线程阻塞。为了方便记忆，我把常见问题整理成了一个对照表：

这个表看起来简单，但排查时非常有用。拿到一个诡异现象，先对号入座，大部分并发故障很快就能归类。

2.3 happens-before 规则：判断并发代码对不对的唯一尺子

有了三大性质，下一步就是怎么判断一段并发代码是否安全。JMM规范的答案是happens-before关系。如果两个操作之间存在如下关系，那么前一个操作的结果对后一个操作是可见的。

常见的几条规则非常有用：程序次序规则，单线程内按代码顺序定义；监视器锁规则，同一个锁的解锁happens-before后续加锁；volatile变量规则，对一个volatile字段的写happens-before后续对这个字段的读；线程启动规则，主线程调用start() happens-before新线程内的所有动作；线程终止规则，线程中的所有动作happens-before其他线程成功join返回；传递性，A happens-before B，B happens-before C，则A happens-before C。

用这些规则排查，比凭感觉靠谱得多。比如你在线程里写了一个普通int变量，主线程用Thread.join等它结束，因为join满足线程终止规则，主线程一定能看到子线程写的值。但如果主线程是在循环里用Thread.sleep等标志位，sleep不产生任何happens-before关系，那标志位就必须加volatile或者用锁。

很多同学搞不清为什么“明明本地跑得很稳”，到线上就是不一致。因为本地测试时，线程调度、CPU缓存、JIT重排恰好没有制造出那个时序；但只要你违反了happens-before规则，事故只是早晚的事。这是典型的“真香就要懂原理”的讽刺场景。

3. 一个真实事故复盘：并发改造是怎么炸的

3.1 事故现场：计数器丢了，线程卡循环

为了讲清楚，我用一个虚构但高度典型的事故来复盘。某公司的订单网关服务原来用一个单线程的统计任务汇总订单数量，一切正常。后来为了吞吐，A同学把它改成多线程并发处理，只动了几行循环，上线后指标就开始异常。

先是压测时统计总数总是小于实际处理量，业务方以为漏单，查了很久日志也没找到丢弃逻辑。然后是偶发的一个消费者线程卡在某个循环里，CPU占用居高不下，重启才恢复。这两类问题放在一起，几乎就是教科书级的原子性加可见性问题。

先看统计逻辑简化后的代码：

public class OrderCounter { private int count; public void incr() { count++; } }

处理线程分别生成一批订单，每个订单调一次incr。按理说最终count应该等于订单总数。但count++在字节码层面是getstatic、iadd、putstatic三步，线程A执行到iadd还没putstatic时，线程B也getstatic，两个线程读到同一个旧值，各自加1写回，最终只增加1。订单量大时，这种丢更新会不断累加。

再看第二个问题，主线程想停止一个工作线程：

boolean stop = false; Thread worker = new Thread(() -> { while (!stop) { // 处理订单 } }); worker.start(); // 某处，主线程设置 stop = true stop = true;

这段代码里stop不是volatile，工作线程完全可能一直读到自己工作内存里的false，即使主线程已经把true写回主内存。这不是玄学，就是JMM的可见性规定。

3.2 用内存模型推导根因，而不是瞎猜

遇到这种事故，我建议先别急着加锁。先把共享变量列出来，逐个判断原子性、可见性、有序性。计数器count的问题在于原子性，stop标志的问题在于可见性。用happens-before规则看，主线程对stop的写和工作线程对stop的读之间没有任何规则能让写先于读发生，所以结果不受保护。

然后再用工具确认。用jps找到进程号，jstack打印线程转储，能看到工作线程长期处于RUNNABLE状态，CPU占比高。虽然无法直接看出内存可见性，但结合代码里没有同步块的现状，基本可以锁定根因。

顺带一提，这类问题最怕的是用“多跑几次”来验证。可见性问题可能几百次才出现一次，而且跟CPU核数、JIT编译状态有关。你就算本地连续跑一万次正常，也不代表线上安全。根因分析必须从模型上证明，而不是靠运气压测。

3.3 修复方案与验证

计数器改法很简单：要么用synchronized把count++包起来，要么用AtomicInteger。这里我通常优先选AtomicInteger，因为它用CAS，没有锁竞争时性能更好；但如果并发极高，CAS也有自旋开销，需要测试后决定。重点是修完之后，count的原子性有了，可见性也就有了，因为AtomicInteger内部有volatile语义。

stop标志改法更简单：把变量声明成volatile boolean stop。volatile保证写变量时强制刷新到主内存，读变量时强制从主内存读取，并且禁止相关重排。这样就建立了两条happens-before关系，问题消失。

修复后不要只在功能上验证，要回到原来的压测场景跑稳定性测试。我用固定线程数和订单量，跑了半小时，count和实际量一致，CPU也恢复了正常水平。这个案例里的每一行代码都很普通，但背后全是内存模型的知识。没有这些知识，你只会把代码改得更花哨，然后炸得更华丽。

4. volatile、synchronized 与并发原语的底层真相

4.1 volatile：轻量级的可见性机制

volatile常被误解成“把变量放到主内存里直接读写”，准确的说法是：对volatile变量的读和写会插入内存屏障，从而保证可见性和有序性。写volatile时，JVM在当前写操作之前插入StoreStore屏障，在之后插入StoreLoad屏障；读volatile时，会插入LoadLoad和LoadStore屏障，确保后续普通读不会读到旧值。这些屏障针对CPU缓存而言，就是让其他核心的缓存行失效，下次读取必须从主内存拉最新值。

但它为什么不保证原子性？因为volatile只管读写这个步骤本身，无法阻止多个线程“同时读到旧值再各自写回”。要解决复合操作的原子性，还是得靠原子类或锁。所以一个很常见但错误的想法是“我声明了volatile，并发就安全了”。不是的，volatile只解决可见性和有序性。

典型用法有两个。一个是状态标志，就是前面说的stop；另一个是双重检查锁里的实例字段。这两个场景都不需要复合更新，所以volatile恰到好处。

还应该注意，volatile在JMM里的happens-before规则是：对一个volatile变量的写，happens-before后续任意线程对这个volatile变量的读。这个规则让它可以用来“发布”之前普通变量写入的结果：你先把数据写进普通变量，再写volatile标志，另一个线程读到flag为true后，再看普通变量，一定能看到之前的写。这在实现无锁发布时非常有用。

4.2 synchronized：重但稳的全局协调者

synchronized由JVM提供，字节码上是monitorenter和monitorexit两个指令，核心是监视器锁monitor。线程进入同步代码块前必须持有锁，离开时释放锁。最关键的是，JMM规定释放锁时会把工作内存中的共享变量刷新到主内存，获取锁时会重新从主内存加载共享变量到工作内存。所以synchronized一次就同时解决了原子性、可见性和有序性。

很多人问，是不是只有被synchronized保护的代码块内的变量才同步？不是。JMM关注的是锁的关系：如果线程A持有锁并在块内修改了一些变量，线程B等同一把锁后才进入，那么A在解锁前做的所有写，B在加锁后都能看见。这就是监视器锁规则。范围是整个临界区，而不只是某个变量。

再说一句性能。JVM对synchronized做了大量优化，比如偏向锁、轻量级锁、锁消除等。锁会让线程阻塞，但绝大多数应用的锁竞争没那么激烈，先追求正确再说性能。等真的压测发现锁是瓶颈，再考虑用其他机制。不要从一开始就造轮子，否则很容易写出一个自以为无锁但实际有严重漏洞的方案。

4.3 并发原语选型：别什么都上无锁，也别什么都用锁

弄清原理后，选型就顺理成章。简单计数：AtomicInteger或LongAdder。读多写少的配置场景：用volatile发布不可变快照。需要复合操作或临界区：synchronized或ReentrantLock。性能敏感且能容忍最终一致：用并发集合类的弱一致性行为。

在实际项目中，我见过更离谱的：有人把所有方法都加上synchronized，并发直接串行化，吞吐掉了一半。也见过另一种极端：为了无锁而用CAS手撸复杂结构，最后bug比功能多。真正稳的做法是先用最直观的同步工具保证正确，再根据压测数据决定要不要优化。原则只有一条：并发正确性没有捷径，原理没吃透前，任何“香”都可能变成事故。

5. 常见问题与避坑清单

5.1 经典坑：双重检查锁为什么必须加 volatile

单例模式里有个被说了无数次但仍有人踩的坑。先贴错误版本：

public class Singleton { private static Singleton instance; public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } }

这里的问题在instance = new Singleton();不是一步完成的。JVM可能先分配内存，再调用构造方法，最后把引用写入instance。在指令重排后，可能分配内存后直接把引用赋值给instance，而构造方法还没有执行完。另一个线程看到instance非null，直接返回，用到的却是一个未初始化对象。

修复方法是把instance声明为volatile。volatile禁止了对该字段的写操作与之前的构造操作重排，保证对象完整发布。这就是有序性在实际代码里的典型体现。

另外，现在有更好的写法：静态内部类或枚举单例。如果只是为了最安全的单例，直接用静态内部类更省心。但作为面试题和排错案例，双重检查锁依然是理解JMM的最佳教材。

5.2 排查并发问题的实用步骤

我踩过的坑多了之后养成了一套流程，分享出来。第一步，把代码里的共享变量全部列出来，标注读写位置。第二步，判断每个共享变量是否在某种同步机制保护下，比如锁、volatile、原子类。第三步，用happens-before规则逐个验证读写之间是否存在可见性保证。这和代码审查是同一套思路，但比靠直觉更可靠。

如果问题已经发生，先用工具确认现场。jps拿到进程号，jstack看线程为什么卡住，jmap或jcmd看内存分配。如果怀疑锁问题，线程转储里会有明显的BLOCKED等待。如果怀疑可见性，线程状态是RUNNABLE但重复执行同一个循环，那就去看代码里是否有同步块。

复现问题时要控制变量。先用一个线程跑，确认基础功能没问题；再逐步增加线程数。每个线程跑完打印当前状态。不要一开始就开20个线程然后满屏日志。日志太多反而掩盖了真正的时序。

5.3 几条独家避坑建议

第一，所有的状态标志、缓存值、配置开关，只要会被多个线程读写，先加volatile。虽然volatile不是银弹，但它成本低，而且能减少大半的可见性问题。

第二，不要在循环里创建大量短命对象，这会加剧GC压力，导致并发性能劣化。配合JVM内存知识去看，很多“并发慢”其实不是锁的问题，是GC频率的问题。

第三，ThreadLocal用完记得remove。ThreadLocal本身不是JMM的范畴，但它和线程生命周期绑定，线程池里线程不退出，不remove就会让集合里的对象一直堆在内存里，造成内存泄漏。这种问题排查起来，比可见性问题还隐蔽。

第四，任何多线程修改共享状态的代码，都先写注释说明“这是哪个线程修正的、通过什么happens-before关系让其他线程看到”。备注写不出来，说明你还没想清楚，八成会炸。

最后分享一点个人体会。JVM架构和Java内存模型每年都被讨论，但很多同行只是在面试前背一背八股，真到改并发代码时，还是凭感觉。其实这些概念的价值恰恰体现在线上故障里：拿到一个诡异现象，你如果能快速判断出是原子性、可见性还是有序性，就不会再靠加日志碰运气。我后来发现，把这套模型当成排查故障的坐标系用，比任何技巧都实用。希望这篇能把原理讲透，让你在“真香”的框架和工具之外，也能稳稳握住底层这根弦。