企业官网建设流程全解析

写这个系列到今天已经是第324篇了。这一篇想认真聊一聊JVM，以及围绕它长出来的那一整套Java技术体系。这些年面试、带人、做技术选型，我观察到一个共性现象：很多开发者的技术栈是“应用层很厚，底层很薄”。Spring用得飞起，各种框架信手拈来，但一旦问到JVM的内存模型、类加载机制、GC算法演进，或者让你解释一下Java 8到Java 21的语法变化到底解决了什么问题，很多人就开始含糊了。

这篇“上篇”专门用来补地基：从JVM的核心机制、Java语言特性的演进，到核心类库和工程化工具链，把Java技术体系的全貌骨架给搭出来。下篇再讲应用框架、中间件和云原生相关的部分。这篇适合两类人：一类是刚工作两三年、想系统性梳理Java知识的开发者；另一类是写了很多年代码、但总感觉自己在“搬运框架”的老人。内容不绕弯子，尽量用大白话和真实案例把底层逻辑讲清楚。

1. 技术体系全景图：为什么有必要梳理全貌

1.1 体系分层的基本视角

Java技术体系看起来庞杂，但它的结构其实是分层的。最底下是操作系统，你写出来的Java代码不可能直接跑在操作系统上，中间必须有一个虚拟机来做翻译和资源管理，这就是JVM。JVM之上是Java标准库，也就是JDK自带的那一大堆类库，集合、并发、I/O、网络、反射、注解都在这一层。再往上才是你平时用的各种框架和中间件，比如Spring、消息队列、缓存中间件、微服务组件这些。最上面才是具体的业务系统。

这个分层模型解释了为什么Java能保持那么长的生命力。你的业务代码可以不用关心底层的GC算法是G1还是ZGC，只要你的应用架构和部署参数合理，换一套垃圾回收器可能只是改个启动参数的事情。反过来，当系统出现CPU飙高、内存溢出、频繁Full GC的时候，你连JVM在干什么都不知道，那就只能在日志里大海捞针。

在我的实际经验里，很多线上故障最后都归结到底层机制的理解偏差。比如一个服务突然STW时间变长，有人怀疑是代码逻辑问题，结果查下来是堆开得太小，GC频率本来就高；再比如一个应用启动时反复死循环，其实是因为依赖里有多个版本的类库，触发了类加载冲突。这些问题如果不站在技术体系的角度去看，很难定位到根因。

1.2 “上篇”的边界：讲什么、不讲什么

既然是“全貌”，就必须先划清边界。这一篇的重点放在Java自身的技术体系上，包括四块内容：

• JVM运行机制：内存区域、垃圾回收、类加载、调优参数、诊断工具；
• Java语言演进：从Java 8到Java 21，新特性和语法糖背后的设计动机；
• JDK核心类库：集合、并发、I/O、反射、注解与泛型这些每天都要用的能力；
• 工程化工具链：构建工具、模块化实践、可观测性与通用排查手段。

下篇才会结合开发框架和中间件去讲业务应用的搭建逻辑。为什么这么分？原因是很多人把Java技术体系理解成了“框架集合体”，学了一堆框架却不知道语言本身和虚拟机的边界在哪里。其实框架随时可能过时，但JVM和语言底层的规律没有变，理解了这部分，换框架只是熟悉API的过程。

需要提前说明的一点是，这篇文章里不会刻意罗列所有的新特性。Java每年都在发新版本，逐条列API没有意义。我更想做的是把那些“改变开发者心智模型”的关键节点标记出来，让你读完之后能形成一条清晰的主线，而不是一堆零碎的知识点。

2. JVM：一切运行的基石

2.1 内存区域的划分与演进

JVM运行时数据区是理解一切内存问题的起点，也是最容易在面试和实战中翻车的地方。简单来说，JVM把内存划分成了几个区域：程序计数器、虚拟机栈、本地方法栈、堆、方法区。

程序计数器是每个线程私有的，用来记录当前线程执行的字节码行号，逻辑上它占得极小，几乎不会出问题。虚拟机栈也是线程私有的，每调用一个方法就会创建一个栈帧，栈帧里保存着局部变量表、操作数栈、方法返回地址等。这个区域最经典的问题就是栈溢出，比如递归没有出口，StackOverflowError就会扑面而来，问题本质上就是栈帧数量超出了栈深度限制。

堆是Java对象的主要栖息地，也是GC管理的重头戏。几乎所有new出来的对象都堆在这里。堆又可以细分为新生代和老年代，新生代里还有Eden区和Survivor区。很多线上配置堆大小、查看GC日志都要围绕这个结构来展开。方法区在JDK 8之后被“元空间”取代，主要用于存储类元信息、常量、静态变量等数据。这个变更最大的实际影响是：方法区不再使用JVM堆内存，而是使用本地内存，于是类元数据的容量不再受堆大小限制，但会受到操作系统本地内存的限制。

说到内存区域的演进，字符串常量池的迁移也值得一提。JDK 7之前，字符串常量池在方法区里；JDK 7之后把它移到了堆中。这个变动不是一个简单的搬家，它直接影响了你new String和字面量字符串的内存位置，也在某些场景下改变了触发GC的时机和压力分布。如果你在排查字符串相关的大对象问题时，知道它在堆里和知道它在方法区里，排查路径是完全不同的。

我画表格的习惯是拿来对照看的，下面这个表可以帮你快速回忆：

2.2 垃圾回收怎么选：从分代到低延迟的取舍

垃圾回收是JVM里最值得花时间研究的部分，因为GC的行为直接决定了应用的响应速度和吞吐量。Java里的垃圾回收器有过很多代，老一点的Serial、Parallel，曾经很流行的CMS，现在占据主流的G1，以及面向未来的ZGC。

Serial适合单线程、小堆、客户端模式，它的回收是单线程的，简单但停顿时间长，基本不存在于现代服务端场景。Parallel也叫吞吐量优先收集器，它主要是多线程并行回收，适合对吞吐量敏感、允许一定停顿的批处理任务。CMS是一套以“获取最短回收停顿时间”为目标的收集器，当年在互联网高响应的场景里非常流行，但对CPU资源比较敏感，而且它会产生内存碎片，JDK 9之后就被标记为废弃了。

G1现在是大规模服务端应用的事实标准。它的核心思路是把堆划分成一个个Region，然后通过追踪各个Region的回收价值和回收成本，来维持一个可预测的停顿时间模型。你可能配置了-XX:MaxGCPauseMillis=200，G1就会在这个目标下尽量调整回收策略。ZGC则是低延迟的代表，它把停顿时间控制在了毫秒甚至亚毫秒级别，这也是为什么越来越多的云原生场景、超大规模内存场景开始使用ZGC。

实际选型的时候，我通常会根据三个维度来评估：吞吐量、响应时间、堆大小。如果是一个大数据批处理任务，停顿时间长一点没关系，但总吞吐量必须高，那Parallel就很合适。如果是高并发、低延迟的在线业务，堆内存几个G到十几个G，那G1是稳妥的选择。如果堆内存到了几十上百G，还要求极致低延迟，ZGC的价值就体现出来了。

需要特别提醒一点：不是越新的收集器就一定越好。GC参数调整是一个典型的“权衡工程”。你降低了停顿时间，往往意味着GC更频繁地执行，或者需要预留更多内存给某些机制，这会带来额外的CPU开销。有些团队一上来就把ZGC配置上了，结果发现某些区域的内存放在特定业务场景下反而产生了更多碎片或更高开销。选择之前，先跑压测，用数据说话，别靠感觉。

2.3 类加载机制：不可忽视的底层逻辑

类加载机制常常被低估，但它在排障时的作用极其重要。JVM加载一个类要经过加载、验证、准备、解析、初始化五个阶段。加载就是找到二进制字节流并转成方法区的运行时数据结构；验证是检查字节流是否符合规范；准备是为类变量分配内存并设置初始值；解析是把符号引用替换为直接引用；初始化才是执行类构造器。

类加载器最常见的是三层结构：引导类加载器、扩展类加载器和应用类加载器。默认的加载逻辑是双亲委派模型，也就是当一个类加载器收到加载请求时，它会先请求父加载器去加载，父加载器加载不了，才自己动手。这套机制保证了Java核心类库不会被用户随意替换，比如你写了一个java.lang.String，它不会被应用类加载器重复加载。

双亲委派模型不是完美的。JDBC这种SPI场景，驱动程序是由不同厂商提供的，核心类库里只是接口，具体实现往往在应用classpath里。这时候如果严格双亲委派，引导类加载器无法加载这些实现类，就会出问题。所以JDK用了线程上下文类加载器来打破这个限制，让核心类库可以反向使用应用类加载器去加载真正的实现。

务实一点说，类加载相关的坑大多数发生在两个点上：jar包冲突和热部署。jar包冲突的典型表现是NoSuchMethodError或者奇怪的ClassNotFoundException，因为多个jar里包含同一个类的不同版本，类加载器加载到的不是你期望的那个。热部署则是通过自定义类加载器来隔离新旧版本类，但如果你不小心让ThreadLocal持有了一次旧类加载器加载的对象，就会造成类加载器无法卸载，最终引发元空间内存泄漏。

排查类加载问题最直接的方式是把类加载的过程打开来看，比如在启动参数里加上verbose:class或者对应的日志开关，看看某个类到底是从哪个jar包加载进来的。这个信息比猜要快得多。

2.4 常用诊断工具与调优参数速查

JDK自带的那一堆命令行工具，我最早觉得它们长得太朴素，后来才发现每一个都极其能打。jps用来查看Java进程；jstat用来监控GC和类加载信息；jmap用来生成堆转储快照；jstack用来查看线程快照；jinfo用来查看和修改运行时的JVM参数。线上排查问题时，这些工具按顺序组合使用，效率非常高。

举个例子，假设一个服务的CPU突然飙到百分之百，第一步先jps找到进程号，第二步top -Hp看是哪个线程在吃CPU，记下线程ID并转成十六进制，第三步jstack导出线程快照，去grep那个十六进制线程ID。你通常就能看到具体是哪个业务线程在忙或者卡在什么地方。这套流程我在线上用过很多次，真能救命。

GC日志也是调优的重要依据。JDK 9开始，GC日志参数改成了统一的日志系统格式，推荐用-Xlog:gc*:file=gc.log这样的方式记录。看GC日志时，我习惯重点看三个指标：GC频率、GC停顿时间、堆使用率曲线。如果年轻代GC很频繁，说明Eden区太小或者对象创建太快；如果老年代持续上涨不回落，大概率是对象没有被及时回收，可能存在内存泄漏。

调优参数选择方面，有几个最基本的：-Xms和-Xmx设置堆的初始和最大值，两者建议设成相同，避免运行时动态扩容带来的性能波动；-XX:MetaspaceSize和-XX:MaxMetaspaceSize控制元空间；-XX:+UseG1GC选择垃圾回收器；-XX:MaxGCPauseMillis设置G1的停顿目标。

下面这个表格是常用启动参数速查：

我自己的习惯是，先把Xms和Xmx设成一致，然后关注GC日志，最后再去调GC收集器和停顿目标。调优不是一次性的活，每次容量评估、每次发布大版本，都应该重跑一次压测看参数是否还合理。

3. 语言特性：从Java 8到Java 21的主线

3.1 Java 8：现代Java的起点

聊Java语言的演进，Java 8是无论如何都绕不开的分水岭。很多企业从Java 8升到Java 17、Java 21，但他们的代码风格还停留在Java 8甚至更早，这不是不行，只是没有吃到语言演进的红利。

Java 8带来的Lambda表达式和Stream API彻底改变了Java的编程方式。Lambda让你把函数当成参数传递，不再需要写一大坨匿名内部类。Stream API则提供了一种声明式的数据处理方式：你要筛选、映射、聚合，直接描述“要什么”，而不是手写循环“怎么拿”。我当时用Stream重构过一个报表统计模块，代码量直接少了一半以上，可读性也好了不少。

Optional接口也是一个容易被低估的设计。它逼着你显式地处理空值，降低空指针异常的风险。当然，Optional不是万能灵药，不该用在字段声明上，也不适合作为无限链式调用的表演舞台。合理用法是作为方法返回值，提醒调用者“这个值可能是空的”。

接口默认方法和静态方法也让接口设计更灵活，集合API因此可以在不破坏现有实现的前提下增加新方法。新的日期时间API则终结了SimpleDateFormat那些线程安全隐患，LocalDate、LocalDateTime配合DateTimeFormatter用起来舒服得多。

3.2 模块化与长期支持版本的关键转折

Java 9最大的事情不是那些语法糖，而是模块化系统JPMS。模块化等于给每个模块声明了依赖谁、导出了什么，让JVM在启动时就能发现缺失依赖，而不是跑到一半才报ClassNotFoundException。不过模块化带来的迁移成本不小，很多老项目在用第三方类库时经常遇到模块访问限制的问题，所以直到今天，依然有大量项目并没有真正用到模块化特性，而是继续使用传统的classpath。

Java 9还带来了JShell这个交互式编程工具。我以前调试一段复杂的集合处理逻辑时，经常需要写一个完整的类再编译运行。有了JShell之后，可以直接在命令行里敲代码验证想法，这对于快速验证API行为非常有用。

Java 10引入了局部变量类型推断，也就是var。它能让代码更简洁，但用的时候要克制，一长串方法调用链里全用var，反而损害可读性。Java 11是一个重要的长期支持版本，最大的动作是移除了一些过时的Java EE模块。从Java 11开始，一些依赖这些模块的老项目在升级时就会遇到麻烦，需要在启动参数里显式加--add-modules，这也是很多人升级Java 11时踩过坑的地方。

3.3 模式匹配与虚拟线程：未来的方向

Java 14和Java 16陆续带来的record、instanceof模式匹配、sealed类这些特性，指向了同一个方向：让Java向“简洁地建模数据”靠拢。record可以让你用一行代码定义不可变数据载体，大幅减少样板代码。sealed类则让继承边界可控，特别适合领域建模中那种“就这几种固定类型”的场景。

真正的重量级选手是Java 21里的虚拟线程。虚拟线程的价值不在于“新”，而在于它改变了我们设计高并发服务的成本模型。传统线程是操作系统线程，创建和切换开销很大，所以线程池需要精细调优。虚拟线程由JVM调度，占用内存极小，你可以为每个任务创建一个虚拟线程，极大地简化了并发编程。

我自己用虚拟线程改造过一个IO密集型的采集服务，原来的设计考虑线程数量、队列容量、拒绝策略，改完之后代码逻辑和同步写法没有任何差别，但并发能力提升非常明显。当然，虚拟线程不是银弹，它最擅长的是高IO等待、低CPU计算的任务。如果任务是纯CPU计算密集型，那么即使换成虚拟线程也不会更快。

文本块、switch表达式、模式匹配for switch这些特性加起来，能明显改善你的代码表达力。但我觉得学习Java新特性的正确方式不是把每个都用到生产环境，而是先看懂它解决什么问题，再挑合适的场景落地。技术选型最忌讳的是为了用而用。

4. 核心类库：每天都在用的那些能力

4.1 集合与并发

Java的集合类库可能是一个人最早接触的东西，但也是很多隐蔽问题的源头。ArrayList基于数组，随机访问快，但插入删除会涉及元素搬移；LinkedList基于链表，插入删除操作更适合，但随机访问性能较差，而且每个节点有额外内存开销；HashMap则是哈希表结构，JDK 8之后引入了红黑树来优化哈希冲突严重的场景。

我见过一个生产事故：一个缓存Map在并发写入后被多个线程读取，结果某些线程看到了奇怪的数据。原因不难判断，HashMap在任何并发场景下都不安全，要么用ConcurrentHashMap，要么用Collections.synchronizedMap做包装。ConcurrentHashMap内部是细粒度锁和CAS的组合，在绝大多数场景下性能和安全性都优于全局锁方案。

JUC包里的线程池也是各类疑难杂症的高发区。ThreadPoolExecutor的核心参数好多人都能背出来，但含义不一定理解透。核心线程数、最大线程数、空闲存活时间、工作队列、拒绝策略，这五个参数彼此牵连。核心线程数不够时任务会进队列，队列满了才会创建更多线程，线程数到最大之后仍处理不过来，就走拒绝策略。如果你的队列用的是无界队列，那么最大线程数和拒绝策略可能形同虚设。

关于线程数怎么定，我一般会把任务分成CPU密集型和IO密集型。CPU密集型建议设置成CPU核数左右，IO密集型可以适当提高，并搭配合理的有界队列。有人还会用公式估算，但公式只是起点，最终还是得靠压测来验证。

4.2 I/O模型与网络编程

Java的I/O经历了BIO、NIO、AIO几个阶段，但真正推动服务端高并发发展的还是NIO。BIO是阻塞式的，每来一个连接就要一个线程处理，并发一高就完蛋。NIO则引入了Channel、Buffer、Selector这套抽象，一个线程可以管理多个连接，大幅度减少了线程开销。

Netty的出现让NIO的使用门槛大幅降低，很多中间件底层都在用类似的模型。但也正因为框架帮你封装好了Reactor模型，很多开发者反而忽略了NIO本身的底层机制。我遇到过好几次诡异的连接池问题，最终排查下来都和Buffer的读写状态、Selector的注册管理有关。建议至少要知道ByteBuffer里的position、limit、capacity是什么含义，flip和clear什么时候调用，这些知识在排查线上问题时会变成救命稻草。

网络编程里，超时设置往往是被忽视的软肋。连接超时、读取超时、写入超时，每一个都要显式设置。某些内部服务一开始没有设置读取超时，结果下游一个慢查询，上游线程成片阻塞，最终拖垮整个应用。这类问题的排查看起来是线程池耗尽，根因却在网络模型的超时策略上。

4.3 反射、注解与泛型的协作逻辑

Java的反射、注解和泛型是框架底层赖以生存的三件套。反射让程序在运行期获取类的信息并调用方法，注解则是给元数据打标记。Spring做依赖注入时，先通过注解识别需要处理的字段和方法，再通过反射完成对象的创建与装配，整个过程在没有这些能力的时候要靠大量手写代码才能完成。

泛型则经常让新手困惑。泛型是编译期的概念，它提供的是类型安全检查，类型信息在编译完成后会被擦除。这就是为什么你可以在运行期通过反射拿到某个字段的注解，但想通过getGenericType去还原泛型真实类型时，情况会变得很复杂。实际开发中，很多框架为了绕过泛型擦除，会要求你显式传入Class对象，或者用TypeToken之类的技巧来捕获泛型类型。

有一个实用的建议：注解本身要做到可重复、有清晰的ElementType和RetentionPolicy定义。RetentionPolicy有CLASS、RUNTIME、SOURCE三种，运行时需要读的注解一定得是RUNTIME。我曾见过某个团队用了默认的CLASS保留策略，结果自定义注解在运行时总是读不到，排查了很久，其实就是保留策略没设对。

5. 工程化工具链：从编译到运行

5.1 构建工具的选择

Java生态里两大构建工具是Maven和Gradle。很多老项目在用Maven，因为它稳定、约定优于配置，POM文件的依赖模型很清晰。Maven的坐标机制用groupId、artifactId、version唯一定位一个jar，依赖冲突时可以通过依赖树来分析。Gradle则用基于Groovy或Kotlin的DSL来写构建脚本，配置更灵活，增量构建和并行构建让大型项目的构建速度更快。

选型建议上，我主要看团队熟悉度和项目规模。中小项目用Maven没什么毛病，资料多、问题好搜。大型多模块项目，Gradle的速度优势很大，但学习曲线更陡峭一些。不管用哪个工具，依赖版本管理都应该从一开始就建立规范，否则几十个模块的依赖更新就会变成一场灾难。

我现在做一个新项目时，习惯把公共依赖版本号收敛到统一的地方去维护，让每个模块尽量不重复声明版本号。这样升级依赖版本时只动一处，风险可控。构建工具本身不是生产力所在，稳定、可复现的构建过程才是。

5.2 包结构与模块化实践

包结构设计是很多Java项目的盲区。包不是文件夹那么简单，它还承担着访问控制的职责。Java的protected和默认访问权限与包结构紧密绑定，合理地设计包层次，能自然地把某些实现类隐藏起来。

我通常推荐按业务能力或领域划分包，而不是按技术分层划分包。按controller/service/dao这种技术层分包，在项目初期清晰，但业务逻辑一旦复杂，各个业务模块的代码就纠缠在一起。按业务域分包，每个业务域自包含接口、实现和基础设施，代码内聚性更强，也更好做模块边界控制。

JDK模块化还没在普通业务项目中普及之前，我们能做的就是利用包结构和依赖管理工具做好“逻辑模块化”。可以定义一个模块的对外接口包，其他模块只依赖这个包，不依赖内部实现包。这种约束虽然要靠团队自律来维护，但配合代码评审和依赖分析工具，效果非常明显。

5.3 可观测性：日志、指标与诊断

Java服务真正跑起来之后，可观测性决定了你排障的速度。日志是最基础的一层。日志框架的选择和用法都有讲究，不要用System.out打印日志，也不要在循环里反复拼接字符串。统一日志门面、按级别记录、保留可追踪的业务上下文，这三件事能做到，日志基本够用了。

再往上是指标监控。JVM自身的CPU、内存、GC情况需要暴露出来，通过监控平台画曲线。我自己最关注的是Full GC频率、老年代使用率、线程池活跃线程数这几个曲线，它们通常比业务指标更早暴露问题。配合像Prometheus这类监控体系，可以做到提前告警，而不是等业务方投诉了才后知后觉。

链路追踪在微服务场景下几乎是必需品。一个请求跨多个服务，单看各服务日志很难定位瓶颈，链路追踪可以把一次请求穿起来，展示每个环节的耗时和状态。甚至可以把日志里记录的业务ID和链路ID关联起来，这样查问题时能很快从入口一路跟踪到最深处。

诊断层面，除了前面提到的JDK自带工具之外，还有一些高级诊断工具值得掌握。比如基于字节码增强技术的辅助工具，可以在线上服务不重启的情况下查看某个方法的入参和返回值，这对排查无法本地复现的问题帮助极大。但使用时要注意权限控制和数据脱敏，线上环境不能随手乱开。

6. 实战中的常见问题与排查技巧

6.1 内存溢出类型对照

内存溢出是Java应用最经典的故障类型，但很多人看到OutOfMemoryError就开始紧张，不知道从哪里下手。实际上，OOM错误信息已经告诉了你类型，不同的类型对应不同的排查方向。

堆内存泄漏的排查通常是这样的：先通过监控发现老年代持续上涨，触发Full GC但内存不回落到合理水位，然后配合堆转储文件去分析。分析的时候重点看大对象和重复对象，很多时候是某个Map或缓存一直在写入却从不清理。一批缓存数据、一个静态集合、一段ThreadLocal保存的对象，都有可能是泄漏点。

Metaspace溢出的场景在微服务架构里越来越常见，尤其是大量使用动态代理、字节码增强、动态生成类的框架。排查时要看是否有多个类加载器反复加载同一个类的不同版本，以及这些类加载器能不能被正常卸载。

6.2 CPU飙高与线程问题定位

CPU飙高是线上最让人焦虑的问题之一。处理流程前面提过，核心就是jstack结合线程ID。但有个重要前提：线程快照需要在CPU飙高的瞬间多抓几次，因为有时候高CPU是间歇性的，只抓一次可能捕捉不到真正的热点线程。

还有一种情况，CPU看起来很高，但jstack里所有线程都不在执行什么复杂任务，都在等待锁或者等待IO。这时候我习惯再看一下GC日志，因为GC线程也是吃CPU的大户，尤其是频繁Full GC时，CPU占用会非常夸张。Full GC原因的排查思路是：先看堆内存使用率，再看是否需要调整新生代和老年代的比例，最后再看代码里有没有大量的临时大对象创建。

线程死锁问题也经常伴随CPU和响应异常出现。jstack会直接输出死锁检测结果，看到类似Found one Java-level deadlock的字样就基本确认了。排查死锁时，除了看锁的持有关系，还要留意锁粒度和获取顺序是否一致。最简单的规避手段是统一加锁顺序，或者用超时锁避免无限等待。

6.3 依赖冲突与类加载问题

依赖冲突是Java后端最普遍的“小毛病”，它不像内存溢出那么难，但也不容易一眼看出来。典型的报错是NoSuchMethodError、ClassNotFoundException、NoClassDefFoundError，而这些问题的根源往往是目标类被预期之外的jar包加载了。

排查依赖冲突时，我先在构建工具里输出依赖树，看看某个groupId产出了哪些版本。如果发现多个版本并存，就把共用的核心依赖统一版本，排除传递依赖中不需要的旧版本。还有一种方案是使用依赖收敛功能，直接让构建失败，避免冲突版本进入产物。

类加载层面的冲突更隐蔽。比如两个jar包里都有同名类，应用类加载器加载的是A版本，但代码里某个库预期的是B版本，运行时就可能出现晦涩的异常信息。解决办法是定位到具体类是从哪个jar加载出来的，再去决定是升级还是排除。这里可以配合前文提到的class加载日志来确认。

还有一个值得注意的坑：某些场景想打破双亲委派模型，比如自定义类加载器来实现类的隔离。但类加载器共享静态变量的问题很容易被忽略，不同类加载器的同名类之间看似隔离，静态状态却可能被线程上下文影响到。越是复杂的类加载架构，越要提前设计好状态存储的位置。

7. 写在最后的一点个人体会

我写“技术演进中的开发沉思”这个系列，总喜欢把“新东西”和“底层机制”放在一起聊。因为Java这门语言的生态实在太庞大，如果你抓住JVM、语言核心、类库机制和工程化工具这几条主线，再去看那些雨后春笋般的新框架，你会发现它们并没有跳出这些底层约束。

如果你看完这篇“上篇”后，想立刻做点什么来巩固理解，我的建议是：打开你正在跑的一个服务，检查一下它的JVM启动参数，再看看它的GC日志，然后在本地写一个小程序去验证类加载机制和内存分配的过程。很多东西光看文章是记不住的，亲手测过一遍，才算真正长在你身上。

我自己早期在排查线上问题时也走过不少弯路，后来养成了一个习惯：每次定位到一个另类的问题，都会顺手把排查过程整理成一份清单。时间久了，这些清单就成了团队内部的技术手册。Java技术体系的全貌也是如此，它不是一个静态的知识库，而是一张不断演进的地图，我们需要做的，是保持更新这张地图的习惯。