Java进阶路线：JVM与并发编程的正确学习顺序

一、为什么建议“先JVM、后并发”

不少Java开发者在进阶时都会纠结：JVM和并发编程，到底先学哪个？一个常见误区是直接上手线程池、锁、并发容器，遇到可见性、死锁等问题时再临时查资料，结果发现所有并发问题最终都会绕回同一个底层话题——内存。线程间通信的本质是共享堆中的对象，而“共享”带来的可见性、有序性问题，恰恰由Java内存模型（JMM）来约束。

可以说，JVM是并发编程的地基：不理解对象在堆中如何分配、如何回收、如何被多个线程访问，并发知识就只能停留在背诵API的层面。因此，更稳妥的进阶顺序是：先掌握Java内存结构与对象分配，再切入并发编程。下面分三个阶段展开。

二、第一阶段：摸清Java运行时内存结构

Java虚拟机在运行时将管理的内存划分为若干区域，各司其职：

• 程序计数器：线程私有，记录当前线程执行到的字节码行号，是唯一不会发生内存溢出的区域；
• 虚拟机栈：线程私有，每个方法调用对应一个栈帧，存放局部变量表、操作数栈等，栈深度超限会抛出StackOverflowError；
• 本地方法栈：为本地（Native）方法服务，与虚拟机栈作用类似；
• 堆：线程共享，几乎所有对象实例都在堆中分配，是垃圾收集器管理的主战场，也是OOM的高发地；
• 方法区：线程共享，存放类元信息、运行时常量池等。

这一结构并非一成不变。Java 7开始，字符串常量池已从方法区（永久代）迁移到堆中；Java 8则彻底移除永久代，改为使用本地内存的元空间。这意味着常量与静态引用的实际存放位置随版本演进有所调整，排查线上问题时不能死记旧结论。

学习建议：先分清哪些区域线程私有、哪些线程共享，再动手写几段触发StackOverflowError和OutOfMemoryError的测试代码，用异常信息反向印证各区域的职责边界。

三、第二阶段：理解堆布局与对象分配规则

3.1 分代堆布局

主流垃圾收集器大多基于分代收集假说：绝大多数对象朝生夕灭，熬过多次垃圾收集的对象往往生命周期很长。因此堆被划分为：

• 新生代：由一个Eden区和两个Survivor区（常称S0、S1）组成，默认比例约为81；
• 老年代：存放长期存活的对象，新生代与老年代的默认大小比约为1:2。

需要说明的是，堆的具体形态与所选垃圾收集器有关，例如以Region为最小管理单元的收集器在物理布局上有所不同，但“分代”的管理思想是一致的。

3.2 对象分配的核心规则

1. 对象优先在Eden区分配。大多数情况下，新对象通过TLAB（线程本地分配缓冲）快速分配，避免多线程竞争同一块空间。Eden不足时触发Minor GC，存活对象被复制到Survivor或晋升老年代；
2. 大对象直接进入老年代。超过阈值的大对象（典型如超长数组）会被直接放入老年代，避免在Eden和Survivor之间来回复制。部分收集器提供设置该阈值的参数，可按需调整；
3. 长期存活的对象进入老年代。对象每熬过一次Minor GC，年龄加一，达到阈值（默认15）后晋升；
4. 动态年龄判定：若Survivor中同龄对象总大小超过Survivor空间的一半，该年龄及以上的对象可直接晋升，无需等到年龄阈值；
5. 空间分配担保：Minor GC前若老年代可用空间不足以容纳所有可能晋升的对象，会触发担保机制，必要时直接执行Full GC。

3.3 用一次Minor GC串起全流程

设想Eden被连续分配的新对象写满：触发Minor GC，从GC Roots扫描新生代中的存活对象，存活者复制到空的Survivor并年龄加一，放不下的晋升老年代；随后Eden与已用Survivor整体清空，进入下一轮分配。理解了这条流水线，你才能真正看懂GC日志里的每一次动作，而不是对着日志一头雾水。

四、不懂分配规则，就会写出“内存杀手”代码

4.1 一个典型的反面教材

不少代码里能看到类似写法：把文件所有行一次性读入List再遍历处理：

// 反例：一次性把整个文件加载进堆
List<String> lines = readAllLines(new File("temp/test.txt"));
for (String line : lines) {
    // 逐行处理
}

这段代码在文件只有几十KB时毫无问题，一旦用于生产环境的日志、导出文件、批处理数据（动辄数百MB甚至GB），灾难就会显现：

• 每一行文本都会变成一个字符串对象，字符串对象本身连同其内部字符数组都要计入堆开销，实际占用往往是原始文件大小的数倍；
• 超大集合要么形成单一大对象直接挤占老年代，要么制造出海量小对象让GC疲于奔命；
• 若多个线程同时执行此类逻辑，堆会被迅速打满，轻则频繁Full GC导致服务长时间停顿，重则直接OOM。

这正是“不理解堆布局与分配规则”的直接代价：代码功能正确，却在数据规模上升后成为系统最脆弱的一环。

4.2 正确姿势：流式读取，常数级内存占用

try (BufferedReader reader = new BufferedReader(
        new InputStreamReader(
            new FileInputStream("temp/test.txt"), StandardCharsets.UTF_8))) {
    String line;
    while ((line = reader.readLine()) != null) {
        process(line); // 处理完一行即可回收，堆占用保持稳定
    }
}

流式处理的本质是“生产多少、消费多少”，让对象在新生代中快速生灭，由Minor GC低成本回收，避免把压力传导到老年代。同样的思想可以延伸到分页查询、分批拉取、生产者-消费者按需消费等场景——本质都是对“对象分配速率”的主动控制。

五、第三阶段：带着JVM知识切入并发编程

有了内存结构的底子，并发编程中那些“玄学”现象就都有了落点。

5.1 JMM：连接堆与线程的规则手册

Java内存模型规定了所有共享变量存放于主内存（可粗略对应堆中的共享对象），每个线程有自己的工作内存（可理解为线程栈与CPU缓存的抽象）。线程对变量的操作必须先在工作内存中进行，再回写主内存——这套抽象正好解释了三大并发问题：

• 可见性：A线程修改了共享变量，B线程可能因仍在读本地缓存而“看不见”这次修改；
• 有序性：编译器与CPU的指令重排序，可能让另一线程观察到与代码顺序不一致的中间状态；
• 原子性：i++这类复合操作实际是“读-改-写”三步，并发执行时会相互覆盖。

5.2 一个最小可见性示例

public class VisibilityDemo {
    static boolean running = true;
    public static void main(String[] args) throws InterruptedException {
        new Thread(() -> {
            while (running) { } // 若无同步措施，可能永远不退出
        }).start();
        Thread.sleep(100);
        running = false;
    }
}

不加任何同步措施时，工作线程可能始终读取不到running的最新值，循环无法退出。将running声明为volatile后，写操作会强制刷新到主内存、读操作强制从主内存获取，循环得以正常结束。此时再回头看synchronized（同时保证原子性与可见性）、volatile（保证可见性与有序性）、final（安全发布）这些关键字，你就能准确说出它们各自在内存层面保证了什么，而不是机械地背诵“加了就不出错”。

5.3 并发知识的合理推进顺序

建议按以下次序推进：线程生命周期与基本创建方式 → synchronized与锁原理 → volatile与JMM三大特性 → 线程池核心参数与队列策略 → 并发容器与原子类 → 常见并发问题排查（死锁、线程泄漏等）。每学一个知识点，都追问一句：“它在内存层面发生了什么？”这个习惯会让并发知识真正内化为你自己的东西。

六、部署环境的内存意识：别把规格表当真实可用内存

无论应用部署在传统物理机还是云主机上（例如在百度智能云的云服务器实例中运行Java服务），都需要建立一条基本意识：实例规格标称的内存，并不等于JVM可用的最大堆。

• JVM自身、元空间、线程栈、直接内存、代码缓存都会占用进程内存，堆只是其中一部分；
• 容器化部署时更需注意：容器存在内存上限，若堆上限设置得过高，OOM可能发生在堆外，报错信息反而指向“容器被杀”，极具迷惑性；
• 建议在上线前明确堆内、堆外内存的预算划分，并接入日志服务与监控告警类的基础能力，把GC频率、堆使用率、线程数等指标纳入可观测范围，而不是等事故发生后才翻日志。

这一环节恰恰是前两个阶段知识的综合应用：懂分代才能设置合理的新生代比例；懂对象分配才能预估业务高峰期的分配速率；懂线程栈才能在动辄上千线程的服务里算清栈内存开销。

七、一份可落地的学习顺序清单

• 第1～2周：Java内存结构。能徒手画出五大区域并标注线程归属，能解释Java 7/8前后的变化；
• 第3周：对象分配与垃圾收集基础。掌握五条分配规则，能读懂基本GC日志，能独立复现并解释一次OOM；
• 第4～5周：JMM与并发三大特性。跑通可见性示例，说清volatile、synchronized、final各自保证什么；
• 第6～8周：锁、线程池、并发容器。结合业务场景做小规模压测，观察线程数、堆占用、GC频率的变化；
• 长期：用线上问题复盘驱动深化，每一次OOM、长停顿、死锁都值得整理成案例沉淀下来。

自检清单：①能否说清一个对象从new到回收的完整旅程？②能否解释一次Minor GC中每个区域的动作？③能否分析一段代码的内存占用量级？④能否指出一段并发代码在内存层面的风险点？四问全部回答“是”，JVM与并发才算真正入门。

结语

回到最初的问题：JVM和并发编程的学习顺序，答案是“JVM在前，并发在后”，但两者并非串行割裂——内存结构是主线，并发编程是这条主线在多线程环境下的自然延伸。先用两三周把堆布局与对象分配规则吃透，再学并发，你会发现许多原来看似孤立的结论突然连成了一张网络。进阶没有捷径，但顺序对了，每一步都算数。