Java 生产级工程实践：从函数式编程到故障诊断与 Kubernetes

写 Java 业务代码并不难，真正拉开工程能力差距的，往往是代码进入生产之后的那一段：如何用更清晰的方式表达业务逻辑，如何理解线程、内存、GC 与网络的真实运行状态，如何在没有 Debugger 的生产环境里留下证据并定位根因，以及应用迁移到 Kubernetes 后如何重新认识 CPU、内存、Pod 生命周期和故障现场。本文把这些问题放到同一条工程链路中，从 Java 8 的函数式编程讲到 JVM 诊断、Wireshark、MAT、Arthas，再延伸到容器化运行和 Java 工程师的能力成长路径。

Java 工程能力真正难在哪里

一个 Java 服务从代码写完到稳定运行，中间其实经过了几次完全不同的能力切换。

编码阶段关心的是表达能力：同一段过滤、转换、聚合逻辑，是写几十行临时变量和循环，还是把意图清楚地表达成一条数据处理流水线。运行阶段关心的是 JVM、线程、内存、GC、网络和数据库。进入生产环境后，问题又变成了另外一种形态：你通常不能单步调试，故障现场稍纵即逝，服务还必须先恢复。迁移到 Kubernetes 后，连“机器有多少 CPU”“进程为什么被杀”“Pod IP 是否还能访问”这些过去习以为常的前提都会变化。

所以，生产级 Java 工程能力不是某一个框架的熟练度，而是下面这条链路能不能真正闭环：

flowchart LR
    A[代码表达] --> B[运行时理解]
    B --> C[日志与监控]
    C --> D[故障证据]
    D --> E[定位根因]
    E --> F[修复与验证]
    F --> G[复盘与工程改进]
    G --> H[容器化与平台化]
    H --> C

本文按照这条链路展开。前半部分从 Java 8 开始，因为 Lambda、Stream、Optional、并行流并不只是语法糖，它们会改变我们组织业务逻辑的方式；中间重点讨论生产排障的方法和工具；后半部分再把这些经验带入 Kubernetes，最后回到工程师自身的成长路径。

Java 8 改变的不是语法，而是代码组织方式

Java 8 带来的 Lambda、Stream、Optional 和函数式接口，很容易被理解成“少写几行代码”。这只说对了一半。真正重要的变化是：把变化的行为本身变成可以传递、组合和复用的数据。

Lambda 的核心是函数式接口

匿名内部类的问题并不只是代码长。它把一个很简单的行为包裹在类名、方法定义和样板代码里：

new Thread(new Runnable() {
    @Override
    public void run() {
        System.out.println("hello");
    }
}).start();

使用 Lambda 后，真正重要的行为被直接留下：

new Thread(() -> System.out.println("hello")).start();

Lambda 之所以能进入 Java 原有的静态类型系统，关键在于 Functional Interface（函数式接口）。函数式接口只有一个抽象方法，因此一个 Lambda 表达式可以被转换成这个接口的实例。

例如 Supplier<T> 的核心只有一个 get()：

@FunctionalInterface
public interface Supplier<T> {
    T get();
}

于是下面两种写法都可以构造一个 Supplier<String>：

Supplier<String> supplier1 = () -> "OK";
Supplier<String> supplier2 = String::new;

Java 标准库在 java.util.function 中已经提供了大量常用接口。业务代码在自定义函数式接口之前，应该先看标准接口能不能覆盖需求。

接口	输入	输出	常见用途
Predicate<T>	T	boolean	条件判断、过滤
Function<T, R>	T	R	类型转换、映射
Consumer<T>	T	无	消费数据、产生副作用
Supplier<T>	无	T	延迟提供数据
UnaryOperator<T>	T	T	同类型转换
BinaryOperator<T>	T, T	T	同类型二元运算

这些接口不仅能被 Lambda 实现，还可以继续组合：

Predicate<Integer> positive = i -> i > 0;
Predicate<Integer> even = i -> i % 2 == 0;
boolean ok = positive.and(even).test(2);

Function<String, String> upper = String::toUpperCase;
Function<String, String> duplicate = s -> s + s;
String result = upper.andThen(duplicate).apply("test");

Consumer<String> println = System.out::println;
println.andThen(println).accept("hello");

这里真正值得学习的是“组合”思想。过去一个方法中如果有一小段逻辑会变化，我们往往通过继承、策略类或匿名类去处理；有了函数式接口之后，可以把变化点直接提升成参数，让公共流程保持不变。

Stream 是一条描述数据变化的流水线

Stream 最适合解决集合的过滤、转换、聚合问题。传统写法通常需要中间集合、临时变量和循环控制：

private static double calc(List<Integer> ints) {
    List<Point2D> points = new ArrayList<>();
    for (Integer i : ints) {
        points.add(new Point2D.Double((double) i % 3, (double) i / 3));
    }

    double total = 0;
    int count = 0;
    for (Point2D point : points) {
        if (point.getY() > 1) {
            total += point.distance(0, 0);
            count++;
        }
    }
    return count > 0 ? total / count : 0;
}

同样的意图用 Stream 可以直接写成：

List<Integer> ints = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8);

double average = ints.stream()
        .map(i -> new Point2D.Double((double) i % 3, (double) i / 3))
        .filter(point -> point.getY() > 1)
        .mapToDouble(point -> point.distance(0, 0))
        .average()
        .orElse(0);

这段代码最重要的不是“从二十行缩成了五行”，而是每一步都有稳定语义：

原始数据
  -> map      对象转换
  -> filter   条件过滤
  -> mapToDouble 映射为数值
  -> average  聚合
  -> orElse   空结果兜底

读代码的人不再需要从循环、临时变量和 if 中反向猜测意图。

Stream 的一个实用入门路径也很明确：先从项目里所有“遍历 List 后做过滤或字段转换”的代码开始，把最简单的 for + if + add 改造成 filter + map + collect/toList。等这类模式熟悉之后，再使用 flatMap、groupingBy、partitioningBy、reduce 等更复杂的操作。

如果团队里大量代码仍然是匿名类和传统集合循环，也不必一次性手改。IntelliJ IDEA 的 Inspection 和 Refactor 可以直接识别“匿名类可替换为 Lambda”“循环可替换为 Stream”等模式，也可以在阅读困难时反向把 Stream 展开成循环。工具的价值不是强迫所有代码函数式化，而是帮助团队逐步建立对两种表达方式的等价理解。

checked exception 为什么会让 Stream 变难用

Java 标准函数式接口通常不声明受检异常。例如 Function<T, R> 的 apply 不允许直接抛 IOException，所以在 Stream 里调用 Files.readAllLines 之类的方法时，容易出现一层层 try/catch。

一种常见处理方式，是定义一个可以抛异常的函数式接口，再统一转换为普通 Function：

@FunctionalInterface
public interface ThrowingFunction<T, R, E extends Throwable> {

    R apply(T t) throws E;

    static <T, R, E extends Throwable> Function<T, R> unchecked(
            ThrowingFunction<T, R, E> function) {
        return value -> {
            try {
                return function.apply(value);
            } catch (Throwable e) {
                throw new RuntimeException(e);
            }
        };
    }
}

这样可以把文件递归搜索写成一条相对完整的数据管道：

try (Stream<Path> paths = Files.walk(Paths.get("."))) {
    paths.filter(Files::isRegularFile)
            .filter(path -> path.toString().endsWith(".java"))
            .flatMap(ThrowingFunction.unchecked(
                    path -> Files.readAllLines(path).stream()
                            .filter(line -> line.contains("public class"))
                            .map(line -> path.getFileName() + " >> " + line)))
            .forEach(System.out::println);
}

这个技巧很实用，但也有代价：受检异常被包装成运行时异常后，异常边界会发生变化。生产代码要确保上层仍然有清晰的错误处理、日志和资源清理策略，不能只是为了让链式代码“看起来漂亮”而把异常语义抹掉。

Optional 解决的是“缺失值语义”，不是把 null 藏起来

Optional 的价值在于显式表达“这个结果可能不存在”。常见写法包括：

String value = Optional.ofNullable(maybeNull)
        .map(String::trim)
        .filter(s -> !s.isEmpty())
        .orElse("default");

Java 8 中常见的方法有：

• empty()：创建空 Optional；
• of(value)：值不能为空，否则直接抛 NPE；
• ofNullable(value)：允许传入 null；
• map() / flatMap()：继续转换；
• filter()：条件过滤；
• orElse() / orElseGet()：提供默认值；
• orElseThrow(Supplier)：无值时抛异常；
• ifPresent()：有值时消费。

这里需要做一个版本澄清：Optional.stream() 并不是 Java 8 API，而是 Java 9 之后才出现。阅读旧课程、旧博客或跨版本代码时，这种“文章主题是 Java 8，但示例表格里混入后续 JDK API”的情况并不少见，最终还是要以目标 JDK 的 API 为准。

另外，orElse 与 orElseGet 不应随便互换：

// 即使 optional 有值，createDefault() 也会先执行
value.orElse(createDefault());

// 只有确实没有值时才执行
value.orElseGet(this::createDefault);

当默认值构造昂贵或带副作用时，后者通常更合适。

Java 8 对集合 API 的函数式增强

函数式编程并不只存在于 Stream。很多传统 API 在 Java 8 之后都加入了“把行为作为参数”的能力。

一个典型例子是缓存加载。传统代码通常写成：

Product product = cache.get(id);
if (product == null) {
    product = loadProduct(id);
    if (product != null) {
        cache.put(id, product);
    }
}
return product;

使用 ConcurrentHashMap.computeIfAbsent 后，可以直接表达“Key 不存在时如何计算 Value”：

private final Map<Long, Product> cache = new ConcurrentHashMap<>();

private Product getProductAndCache(Long id) {
    return cache.computeIfAbsent(id, this::loadProduct);
}

对于 ConcurrentHashMap，这个操作并不是简单的 get + apply + put 语法糖，映射计算与更新具有更强的并发语义。与此同时，mapping function 应保持短小，避免在里面执行对同一个 Map 的递归更新或非常慢的阻塞操作，否则可能放大锁竞争和等待时间。

并行流不是“加一个 parallel 就会更快”

parallel() 可以把 Stream 切换为并行执行：

IntStream.rangeClosed(1, 100)
        .parallel()
        .forEach(System.out::println);

它的默认执行环境通常是 ForkJoinPool.commonPool()。这带来几个必须明确的事实：

• 并行流不保证 forEach 的 encounter order；
• common pool 是进程内共享资源，一个慢任务可能影响其他并行流和使用 common pool 的异步逻辑；
• CPU 密集型任务和阻塞 IO 任务的并行度设计完全不同；
• 小集合、轻计算、需要强顺序的任务，并行开销可能大于收益。

历史课程中对同一批 10000 个、单任务约 10ms 的任务比较过几种并发实现：直接线程、固定线程池、ForkJoinPool、并行流、CompletableFuture。当并行度都设为 20 时，各方案都能在约 5～6 秒量级完成。这个实验的意义只是证明“并行度确实生效”，并不能作为这些模型的性能排名。

更合理的选择方式是：

模型	更适合的场景	主要风险
直接创建线程	Demo、极少量临时线程	生命周期难管理，数量容易失控
ThreadPoolExecutor	大量彼此独立的业务任务	线程数、队列、拒绝策略必须设计
ForkJoinPool	可递归拆分的小任务、CPU 密集型分治	不适合把大量长时间阻塞任务直接塞进去
parallelStream	数据并行、计算相对纯粹、可接受共享池	common pool 干扰、顺序和阻塞问题
CompletableFuture + Executor	显式异步编排、需要控制执行器	任务链错误处理和线程池设计更复杂

forEachOrdered 也需要正确理解。它会保证有 encounter order 的流按原顺序执行终端动作，因此终端消费部分会失去很大一部分并行优势，但并不等于整条 pipeline 都必然完全串行，上游 filter、map 等阶段仍可能并行执行。

还有一个历史上很容易踩的点：可以通过系统属性调整 ForkJoinPool.commonPool() 的并行度，但公共池在类初始化时就会创建，属性设置得太晚可能根本不生效。更重要的是，这个池是 JVM 进程级共享资源，业务运行过程中动态修改全局并行度并不是好设计。需要隔离容量时，优先使用显式 Executor / ForkJoinPool，让执行资源成为可以配置和监控的依赖。

对于现代 JDK，如果业务已经大量使用 JDK 21+ 的虚拟线程，IO 密集型并发又多了一种很有价值的模型。不过虚拟线程解决的是“阻塞线程成本”问题，并不会自动让 CPU 密集型代码变快，也不能替代限流、连接池和外部依赖容量管理。

生产排障的第一原则：不要猜，要拿证据

开发环境里，只要问题可以稳定重现，单步调试通常能解决大多数问题；测试环境里还可以造数据、压流量、使用 VisualVM、Arthas 等工具附加进程；真正困难的是生产环境。

生产环境通常同时具备三个特点：权限更严格、流量更真实、恢复时间更紧张。出现故障时很难完整保留现场，甚至服务一重启，最关键的证据就消失了。因此，生产排障首先不是“会不会某个命令”，而是有没有能力把过去发生过什么还原出来。

可以把生产排障需要的证据分成三类：

flowchart TD
    A[生产故障证据] --> B[日志]
    A --> C[趋势监控]
    A --> D[瞬时快照]

    B --> B1[应用日志]
    B --> B2[Access Log]
    B --> B3[GC 日志]
    B --> B4[中间件/数据库日志]

    C --> C1[CPU/内存/磁盘/网络]
    C --> C2[JVM/线程/GC]
    C --> C3[连接池/队列/线程池]
    C --> C4[业务指标]

    D --> D1[Thread Dump]
    D --> D2[Heap Dump]
    D --> D3[NMT]
    D --> D4[网络抓包]

趋势告诉你“什么时候开始异常、异常怎么变化”，快照告诉你“某个瞬间内部到底是什么状态”。只看快照而没有趋势，很容易误判；只看趋势而没有快照，又经常知道“出问题了”却不知道“为什么”。

监控必须覆盖真实调用链上的每一层

一套生产监控至少应该覆盖下面几层：

主机和容器层。 CPU、内存、磁盘、文件系统、IO、网络。如果运行在虚拟机或 Kubernetes 中，需要同时看到节点与虚拟机/Pod 的资源状态。

网络层。 网络时延、丢包、带宽、连接数、关键专线或网关状态。

中间件与存储层。 数据库、Redis、MQ、注册中心、网关等不仅要看进程资源，还要看内部指标，例如连接数、慢查询、积压、复制延迟、线程池或队列状态。

应用和 JVM 层。 Heap、Metaspace、GC、线程数、类加载、请求耗时、错误率、线程池、连接池、队列、关键依赖耗时。

业务层。 成功率、交易量、订单量、核心状态机失败数等。很多故障的第一信号并不是 CPU，而是业务指标突然掉到零。

日志同样要分级。生产环境通常不能把所有调试信息全开，但错误和异常必须完整记录。INFO 负责重要流程，WARN 用来提示异常趋势或需要关注的问题，ERROR 代表已经阻断流程的问题；真正用于本地追踪细节的信息才放到 DEBUG/TRACE。

恢复服务与定位根因是两个不同目标

生产事故时最容易犯的错误，是把“先恢复”与“查清楚”混在一起。

如果是明显的新版本 Bug，回滚往往比现场调试更正确；如果是资源耗尽，扩容或重启可能是最快恢复手段；如果外部中间件发生故障，切换备用节点或降级也可能优于长时间排查。

但恢复不能把证据一起抹掉。更合理的过程是：

flowchart TD
    A[发现故障] --> B{能否快速止损?}
    B -->|能| C[回滚 / 切流 / 扩容 / 降级]
    B -->|不能| D[先缩小爆炸半径]
    C --> E[尽可能保留一个现场节点]
    D --> E
    E --> F[收集日志 / 指标 / Thread Dump / Heap Dump]
    F --> G[从大到小分类定位]
    G --> H[确认根因]
    H --> I[修复 + 验证]
    I --> J[复盘 + 补监控 + 自动化]

“重启以后好了”只是恢复，不是定位。没有根因，也没有补上证据链，问题很可能只是进入下一次复发倒计时。

从大到小定位：先判断问题在哪一层

生产问题没有统一的一键答案，但可以先做粗分类。

一类是版本问题。如果发布后立即出现、回滚立即消失，优先从版本 diff、配置变更和依赖升级入手。

一类是外部因素。主机、数据库、Redis、MQ、网络、网关、DNS、证书、路由、连接池都可能让 Java 应用表现成“自己坏了”。

另一类是资源耗尽。CPU 打满、内存泄漏、频繁 GC、磁盘 IO 饱和、网络带宽打满、线程或连接耗尽，都可能让系统表现为“假死”。

下面几类 Linux 工具可以作为第一层排查入口：

方向	常用工具
CPU	top、vmstat、pidstat、ps
内存	free、top、ps、vmstat、sar
IO	lsof、iostat、pidstat、sar、iotop、df、du
网络	ip、ss、ping、dig、tcpdump、iptables/nftables

工具名单本身并不重要，重要的是知道每个工具在回答什么问题。

CPU 高：从操作系统线程一路追到 Java 方法

CPU 高时，一个非常稳定的定位路径是：

flowchart LR
    A[top 查看进程] --> B[top -Hp PID]
    B --> C[找到高 CPU TID]
    C --> D[转为十六进制]
    D --> E[jstack / jcmd Thread.print]
    E --> F[按 nid 搜线程]
    F --> G[定位方法栈]
    G --> H[结合代码 / Arthas 验证]

Linux 上可以先看进程内各线程：

top -Hp <pid>

记下高 CPU 线程的十进制 TID，再转换为十六进制：

printf '%x\n' <tid>

抓线程栈：

jstack <pid> > thread.txt
# 或现代 JDK 中使用 jcmd
jcmd <pid> Thread.print > thread.txt

然后搜索 nid=0x... 对应线程，就能看到 Java 调用栈。

如果没有条件实时执行 top，可以每隔几秒抓一份 Thread Dump。一个线程如果在多份快照里持续处于 RUNNABLE，而且栈位置高度一致，就很可能是热点线程。

CPU 高常见根因不只是死循环：

• 请求量突然增大；
• 外部依赖变慢，导致在途请求和工作线程增多；
• GC 压力增大；
• 算法或循环逻辑异常；
• 锁竞争和上下文切换；
• 编解码、压缩、加密、正则等 CPU 密集型操作意外进入热点路径。

这里必须同时看入口流量。一个系统变慢后线程数上升，可能是“外部依赖先变慢，线程被拖住”；也可能是“流量先变大，线程和 CPU 被打满，最终请求变慢”。慢到底是原因还是结果，不能只看 JVM 内部。

内存问题：堆只是 Java 进程内存的一部分

看到 RSS 很高时，不要下意识等同于“Heap 很大”。Java 进程的内存通常包括：

Java Heap
+ Metaspace / Class Metadata
+ Thread Stack × Thread Count
+ Direct Buffer / Native Memory
+ JIT Code Cache
+ GC / Compiler / JVM Native Structures
+ JNI / 第三方 native library
+ mmap / libc 等其他 native 开销

所以可能出现这样的现象：Heap Dump 看起来很正常，但容器依然因为 RSS 超限被 OOM Kill。

Heap OOM 最直接的保留方式是：

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/path/to/dump

Native Memory Tracking（NMT）则用于观察 HotSpot 自身的 native memory 分类：

# JVM 启动时开启
-XX:NativeMemoryTracking=summary
# 或更细粒度
-XX:NativeMemoryTracking=detail

# 运行时查看
jcmd <pid> VM.native_memory summary
jcmd <pid> VM.native_memory detail

# 建立基线并看增量
jcmd <pid> VM.native_memory baseline
jcmd <pid> VM.native_memory summary.diff

现代 JDK 仍然保留这套能力。需要注意，NMT 本身有运行开销，而且它主要跟踪 HotSpot/JVM 自身的 native memory，并不能替代对第三方 native library 的完整分析。

IO 与网络：很多“Java 性能问题”其实不在 Java 里

磁盘、网络、数据库一旦慢下来，Java 线程会被迫等待，于是你可能看到线程数上升、请求超时、队列堆积，甚至进一步造成内存升高。

网络问题尤其需要拆成三段来看：

客户端 -> 网络传输链路 -> 服务端

数据库访问慢，不一定是数据库本身慢：客户端连接池耗尽、客户端 Full GC、网络丢包、防火墙状态、路由变化，都可能让最终表现看起来像“SQL 慢”。反过来，服务端如果有明确慢查询日志，又能排除网络，那么才应该把重点放回 SQL 与数据库执行计划。

九条很实用的排障经验

生产排障很难写成万能公式，但有一些经验非常稳定。

1. 先判断“鸡和蛋”。 线程多导致慢，还是慢导致线程多；CPU 高导致 GC 变慢，还是内存问题引发频繁 GC 后把 CPU 打满。
2. 通过分类找规律。 是所有机器都出问题，还是只有一台；所有接口都慢，还是只有某类请求；所有线程都异常，还是集中在某个线程池。
3. 按照真实调用拓扑排查。 Nginx -> Ingress -> Service -> Pod 中任何一层都可能失败，看到 502 不能直接跳到 Java 代码。
4. 看到平台型曲线要想到资源上限。 带宽、连接池、线程池、队列长度如果增长到某个固定水平后不再变化，往往已经撞到限制。
5. 资源之间会连锁反应。 内存泄漏可能引发 GC，再引发 CPU 高；磁盘或网络阻塞可能让内存队列不断膨胀。
6. 网络问题永远拆成客户端、链路、服务端三段。 不要默认对端就是罪魁祸首。
7. 趋势工具和快照工具配合。 top/jstat/监控曲线 看变化，jstack/Heap Dump/MAT 看某个时刻的细节。
8. 不要因为经验与监控冲突就先怀疑监控。 如果监控体系对其他应用表现正常，更应该优先相信数据。
9. 没有证据定位不了时，必须补可观测性。 同一个问题如果还能以完全相同方式“消失”，下一次就还会以完全相同方式回来。

这些经验背后的共同思想很简单：排障是在不断缩小可能性空间，而不是寻找一个听起来最像答案的解释。

JDK 自带工具：先学会直接问 JVM

JDK 自带了一整套诊断工具。课程中的案例使用 JDK 8/11 演示，而今天在现代 JDK 中，很多能力仍然存在，只是使用习惯更偏向 jcmd + JFR/JMC，VisualVM 也通常作为独立工具安装，而不是默认跟随 JDK 分发。

常见工具各自解决什么问题

工具	主要用途
jps	查看 Java 进程
jinfo	JVM 参数、系统属性
jstat	GC、类加载、编译等趋势指标
jstack	Thread Dump
jcmd	统一诊断命令入口，线程、Heap、NMT、JFR 等
jconsole	JMX 图形监控、MBean
VisualVM	本地可视化 JVM 监控、采样、Dump 分析
JFR/JMC	低开销事件记录与性能分析，现代 JDK 非常重要

工具不是越多越好。生产环境最值得先熟练的是 jcmd、jstat、Thread Dump、Heap Dump、JFR，再配合操作系统工具。

一个 JVM 参数位置错误就能改变整个结论

下面这条命令看起来像是给 JVM 配了 1GB Heap：

java -jar app.jar -Xms1g -Xmx1g

实际上 -jar 之后的参数已经是程序参数，并不会作为 JVM 参数生效。正确顺序是：

java -Xms1g -Xmx1g -jar app.jar

这类问题不能靠“启动脚本看起来没问题”判断，应该直接问 JVM：

jinfo <pid>
jcmd <pid> VM.command_line
jcmd <pid> VM.flags

这也是整个排障方法论里很重要的一点：配置文件写了什么不等于运行时真正用了什么。

jstat 适合看 GC 趋势

例如每 5 秒输出一次 GC 利用率，总共输出 100 次：

jstat -gcutil <pid> 5000 100

常见列包括：

• S0/S1：Survivor 区使用率；
• E：Eden 使用率；
• O：Old 区使用率；
• M：Metaspace 使用率；
• YGC/YGCT：Young GC 次数和耗时；
• FGC/FGCT：Full GC 次数和耗时。

需要注意，优化 GC 不能只盯“次数”。更应该看吞吐量、暂停时间、分配速率、晋升速率、老年代趋势，以及这些指标对业务延迟的影响。

jcmd 是现代 JDK 最值得熟练的入口之一

先看当前 JVM 支持哪些诊断命令：

jcmd <pid> help

常用命令包括：

# JVM 参数
jcmd <pid> VM.flags
jcmd <pid> VM.command_line

# 线程
jcmd <pid> Thread.print

# 堆
jcmd <pid> GC.heap_info
jcmd <pid> GC.heap_dump /tmp/heap.hprof

# Native Memory Tracking
jcmd <pid> VM.native_memory summary

# JFR
jcmd <pid> JFR.start name=profile settings=profile duration=5m filename=/tmp/profile.jfr

在 JDK 25 中，jcmd 甚至可以直接把 Thread Dump 输出成文件，并支持 JSON 格式。相比记忆大量独立工具，先掌握 jcmd help 往往更高效。

jmap 在老版本排障资料里也很常见。jmap -dump 会转储当前堆，而 jmap -dump:live 只保留 GC Roots 可达的存活对象；后者通常需要先触发 GC，因此在线上大堆应用中要评估停顿影响。现代 JDK 已经能通过 jcmd GC.heap_dump 完成主要 Heap Dump 场景，生产上更应该优先选择团队已经验证过、影响范围清楚的方式。

参数的单位和默认值也必须实测

历史案例中曾出现过一个很典型的问题：开发者希望把线程栈设置为 256KB，却因为某个版本/平台下对 ThreadStackSize 的理解和实际行为不一致，最终通过 NMT 看到线程栈保留空间远超预期。

这个案例真正应该留下的经验不是背某个版本的“神奇单位”，而是：

参数文档
  != 启动脚本
  != JVM 实际生效值

对线程栈这类关键参数，更稳妥的方式是使用明确的 -Xss 写法，并通过 jcmd、NMT、PrintFlagsFinal 等确认最终效果。尤其是升级 JDK 或切换容器环境之后，不要默认旧版本经验仍然完全成立。

Wireshark：把“数据库到底收到了什么”直接抓出来

很多 Java 性能问题最终都要跨出 JVM。一个非常典型的案例是 JDBC 批量插入。

代码已经使用了 JdbcTemplate.batchUpdate：

String sql = "INSERT INTO testuser(name) VALUES (?)";

jdbcTemplate.batchUpdate(sql, new BatchPreparedStatementSetter() {
    @Override
    public void setValues(PreparedStatement ps, int i) throws SQLException {
        ps.setString(1, "user" + i);
    }

    @Override
    public int getBatchSize() {
        return 10_000;
    }
});

从 Java API 看，它确实叫 batch；但“Java 代码调用了 batch API”并不能证明网络上传输的也是批量 SQL。

课程中的真实排查过程是直接使用 Wireshark 抓 MySQL TCP 流量。结果发现，驱动实际上仍然一条一条发送 INSERT，因此 1 万条数据耗时约 26 秒。继续查看 Connector/J 批处理实现后发现，关键参数是：

rewriteBatchedStatements=true

启用后，驱动可以把适合的 INSERT/REPLACE 改写成 multi-values 形式，或把多条语句合并提交，显著减少网络往返。相同案例中，1 万条数据耗时下降到约 253ms。

抓包里还能看到另一个很有价值的细节：一条很长的批量 INSERT 并不对应“一个 TCP 包”。案例中的 SQL 数据大约 138933 字节，而连接的 MSS 大约 16344 字节，因此最终被拆成多个 TCP segment 传输。应用层的一条 SQL、MySQL 协议消息和 TCP 分段不是一一对应关系，分析网络问题时一定要区分协议层次。Wireshark 的 Follow TCP Stream 正是把这些分段重新放回同一个连接上下文中观察。

这个“100 倍”只能理解为当时特定环境下的案例结果，不能直接当作通用基准。真正应该记住的是这个排查链路：

flowchart LR
    A[应用认为自己在批量写] --> B[抓实际 TCP 流量]
    B --> C{MySQL 收到什么?}
    C -->|单条 INSERT| D[检查 JDBC Driver 行为]
    D --> E[确认 rewriteBatchedStatements]
    E --> F[再次抓包验证]
    F --> G[再做性能测试]

当前 MySQL Connector/J 仍然提供 rewriteBatchedStatements，默认值仍是 false。不过实际改写行为会受到 SQL 形态、PreparedStatement、生成键、流参数等条件影响，所以生产性能优化仍然应该遵循“读当前驱动文档 + 抓实际行为 + 压测”的方式。

另一个现代环境差异是 TLS。生产数据库通常启用加密连接，这时 Wireshark 并不能像本地明文连接那样直接看到 SQL 文本。抓包仍然可以用来分析 TCP 重传、连接建立、RTT、RST 等网络问题，但 SQL 层观察可能需要数据库侧日志、Performance Schema、驱动日志或其他可观测工具配合。

MAT：OOM 时不要只看“谁最多”，要看“谁把它留住了”

Heap Dump 的价值在于，它包含某个时刻堆中的对象和引用关系。jstat 可以告诉你 Heap 在不断增长，但不能告诉你到底是哪个对象把内存留下来了；MAT（Eclipse Memory Analyzer）真正擅长的就是回答这个问题。

先理解 Shallow Heap 和 Retained Heap

MAT 中两个概念非常重要：

Shallow Heap 是对象自身占用的大小。

Retained Heap 是如果这个对象被回收，连同它只能通过该对象访问到的其他对象一起能够释放的内存总量。

一个 ArrayList 对象自己可能只有十几个字节，但它引用的 Object[]、几万个 String 以及字符串底层数据加起来可能是几百 MB。真正值得警惕的是后者。

一个完整的 OOM 定位路径

课程中的 Heap Dump 大约 437MB。直方图里大量 char[] 和 String 排在前面，看起来像“字符串把内存吃满了”。继续沿 incoming references 追踪，最终得到了这样的引用链：

FooService
  -> data : ArrayList
    -> elementData : Object[]
      -> String
        -> char[]

其中 FooService.data 的 Retained Heap 达到 431MB，说明真正把这些字符串长期留在堆里的根对象是 FooService 中的 List。

进一步看线程栈，可以发现 FooService.oom() 正在持续生成字符串；再用 OQL 查询 FooService 的实例数量和引用它的对象，又看到 Spring DefaultListableBeanFactory.singletonObjects 中只有一个 fooService，从而证明它是单例 Bean。

最终代码的本质非常简单：

@Component
public class FooService {
    private final List<String> data = new ArrayList<>();

    public void oom() {
        data.add(IntStream.rangeClosed(1, 10_000)
                .mapToObj(__ -> "a")
                .collect(Collectors.joining("")));
    }
}

外部又在循环调用：

while (true) {
    fooService.oom();
}

整个定位过程可以总结成：

flowchart TD
    A[Histogram 看大类] --> B[Dominator Tree 看最大 Retained Heap]
    B --> C[Incoming References 找引用链]
    C --> D[查看对象字段和真实值]
    D --> E[Thread View 看故障时调用栈]
    E --> F[OQL 查询实例与容器关系]
    F --> G[回到代码验证根因]

JDK 8 与现代 JDK 的 String 结构不同

这个案例中的 String -> char[] 是典型的 JDK 8 结构。Java 9 引入 Compact Strings 后，现代 HotSpot 通常使用更节省空间的 byte[] 加编码标记保存字符串。因此今天在 JDK 17/21/25 的 Heap Dump 中，遇到字符串占用问题时很可能看到的是大量 byte[]，而不是 char[]。

这也是做 Heap Dump 分析时很重要的一条原则：不要机械背对象图，要理解所用 JDK 版本的实际对象布局。

Arthas：没有源码也能把高 CPU 一路追到入参

JDK 自带工具擅长提供底层数据，Arthas 的优势则是把很多诊断动作整合到了一起，尤其适合线上快速确认某个方法到底在做什么。

课程中的高 CPU 案例可以完整体现这个过程。

dashboard：先确认大方向

进入 Arthas 后，dashboard 可以先看到线程、CPU、内存、GC 等总体状态：

dashboard

案例中可以看到 CPU 高并不是 GC 导致的，最忙的线程大多属于：

ForkJoinPool.commonPool-worker-*

这马上把方向缩小到了 common pool，很自然地联想到并行流或 CompletableFuture 默认执行器。

thread：找到最繁忙线程的方法栈

thread -n 8

输出中多个热点线程都在执行 MD5。主线程也参与 ForkJoin 任务，因此从栈里进一步定位到业务方法 HighCPUApplication.doTask()。

jad：直接反编译运行中的类

jad com.example.HighCPUApplication

反编译后发现 doTask(int id) 在某个特殊 id 下会执行 1 万次 MD5，于是根因已经非常接近。

watch：只观察真正慢的调用入参

如果代码逻辑很复杂，不知道什么入参触发了慢路径，可以直接看运行时数据：

watch com.example.HighCPUApplication doTask '{params,returnObj,throwExp}' '#cost>100' -x 2

案例中所有慢调用的参数都是 0，于是再通过 ognl 读取静态常量确认：

ognl '@com.example.User@ADMIN_ID'

最终确认特殊管理员 ID 正是 0。

这条排查链非常值得背下来：

flowchart LR
    A[dashboard] --> B[thread -n]
    B --> C[找到业务栈]
    C --> D[jad 反编译]
    D --> E[watch/trace 看运行时数据]
    E --> F[ognl 验证字段或表达式]
    F --> G[确认根因]

Arthas 强大，但生产权限必须更谨慎

watch、trace、monitor 等命令会通过字节码增强实现观测，执行结束后要及时清理增强状态。Arthas 还支持重新定义类实现热修复，这在事故现场非常诱人，但风险也很高：

• 临时修改没有正常代码评审链；
• 操作者权限过大；
• 修改错误会让现场更难解释；
• 热修内容容易与后续正式发布产生偏差。

因此生产环境更适合把 Arthas 定位能力作为受控诊断工具，而不是默认把线上热改当成常规发布方式。

现代 Java 排障还应该补上 JFR

原课程重点使用 jstat、Thread Dump、MAT、Arthas，这套方法今天仍然有效。不过在现代 JDK 中，Java Flight Recorder（JFR）已经成为生产性能分析中非常值得补上的一环。

Thread Dump 是一个瞬间，JFR 则可以持续记录一段时间里的线程调度、锁等待、GC、对象分配、Socket、文件 IO、异常等事件。它正好填补了“趋势监控太粗、单次快照太瞬时”之间的空白。

一个典型使用方式是：

jcmd <pid> JFR.start \
  name=incident \
  settings=profile \
  duration=5m \
  filename=/tmp/incident.jfr

拿到文件后可以用 JDK Mission Control（JMC）分析。如果是“偶尔卡 2 秒”“某段时间延迟暴涨但过后恢复”这类问题，JFR 往往比只抓一份 jstack 更有价值。

可以把现代生产诊断工具理解成下面几个层次：

目标	更合适的工具
看系统资源趋势	Prometheus / Grafana / OS metrics
看 JVM GC 与基础状态	JMX / Micrometer / jstat
看某一刻线程状态	Thread Dump / jcmd Thread.print
看一段时间性能事件	JFR / JMC
看 Heap 引用关系	Heap Dump / MAT
看 HotSpot native memory	NMT
看运行中方法和入参	Arthas
看网络真实报文	tcpdump / Wireshark

Java 进入 Kubernetes 后，原来的机器常识会失效

Java 程序从虚拟机迁到 Kubernetes，业务代码可能一行都不用改，但运行假设已经变了。

在虚拟机里，我们习惯机器 IP 相对稳定、进程退出后机器仍然存在、磁盘上的日志还能进去看、JVM 看到的 CPU 和内存基本就是这台机器的资源。到了 Pod，这些条件都不应该再默认成立。

Pod IP 不稳定：不要把实例地址当成持久身份

Pod 是 Kubernetes 的基本调度单元，Pod 重建后 IP 可能发生变化。因此正常的服务访问应该依赖：

• Kubernetes Service 做集群内服务发现；
• Ingress/Gateway 提供外部入口；
• 或业务自己的注册中心和客户端负载均衡。

真正危险的是一些老系统会把“实例 IP”持久化。例如任务调度系统把执行节点 IP 写入数据库，之后再通过这个 IP 回到原节点读取本地日志。放在虚拟机里可能长期正常，迁到 Kubernetes 后，只要 Pod 重建，历史 IP 就失效。

这种问题不能靠“想办法固定 Pod IP”来掩盖，应该重新设计状态：日志进入集中存储或持久卷，任务记录保存可持久化的执行结果，实例 IP 只作为短生命周期运行信息。

Kubernetes 里的 OOM，先分清是谁杀了谁

“K8s 里 OOM 了”至少可能代表两种完全不同的情况。

JVM 自己抛出了 OutOfMemoryError

最典型的是 Heap 不够：

java.lang.OutOfMemoryError: Java heap space

JVM 仍然有机会执行 OOME 处理逻辑，也可能生成 Heap Dump。之后因为进程退出或健康检查失败，容器再被重启。

容器超过 memory limit，被内核 OOM Kill

另一种情况是整个进程 RSS 超出 cgroup 限制，内核直接杀掉进程。这个时候可能根本没有 Java Heap OOM，因为真正增长的是 Direct Memory、线程栈、native library 或其他堆外区域。

这两类问题的诊断路径完全不同：

flowchart TD
    A[Pod 重启 / OOM 关键字] --> B{JVM 有 OOME 日志?}
    B -->|有| C[Java OOM]
    B -->|没有或 Exit 137/OOMKilled| D[容器 / OS OOM Kill]

    C --> E[Heap Dump / MAT]
    C --> F[GC / 分配速率 / 线程数]

    D --> G[容器 memory limit 与 RSS]
    D --> H[NMT]
    D --> I[Direct Memory / Thread Stack / native]

    E --> J[修代码或调资源]
    G --> J
    H --> J

这里有一个很重要的结论：遇到容器 OOM Kill 时，盲目增大 -Xmx 往往会让问题更严重。 因为 Heap 只是容器内存的一部分，Heap 越大，留给 native memory、线程栈和操作系统的空间越少。

课程里给出的工程经验是把 Heap 控制在容器 memory limit 的大约 50%～70%，为堆外内存和系统留出余量。这个比例只能作为起点，不是通用公式。Netty、大量直接缓冲区、很多平台线程、JNI、复杂类加载场景需要更多堆外空间；纯 Heap 型批处理应用则可能允许更高比例。正确做法仍然是用真实监控把内存构成量出来。

现代 JDK 已经具备更完善的容器感知

早期 JDK 8 在容器内对 CPU、内存限制的识别有很多历史坑。现代 JDK 的 HotSpot 已默认开启容器感知，会根据容器约束计算可用内存和处理器数量。

常用参数包括：

-XX:+UseContainerSupport
-XX:MaxRAMPercentage=...
-XX:InitialRAMPercentage=...
-XX:MinRAMPercentage=...
-XX:ActiveProcessorCount=...

例如：

java \
  -XX:MaxRAMPercentage=60 \
  -XX:InitialRAMPercentage=30 \
  -jar app.jar

MaxRAMPercentage 控制的是 Heap 上限相对于 JVM 认定可用内存的比例，而不是整个 Java 进程 RSS 的比例。
另外 MinRAMPercentage 这个名字很容易让人误解，它并不是“最小堆占比”或 Xms 的直接替代；在现代 HotSpot 中，它主要参与小内存场景的最大堆计算。涉及这几个百分比参数时，应以当前 JDK 的 java 参数文档和运行时实际值为准，不要仅凭参数名猜含义。

CPU 同样不能只看 Kubernetes YAML。JVM 会根据 active processor count 决定 GC 线程、JIT 编译线程、ForkJoinPool 并行度等参数。如果 CPU 识别不符合实际容量，会造成并发过高或过低。

现代 JDK 可以直接确认：

java -XX:+PrintFlagsFinal -version | grep -E 'ActiveProcessorCount|ParallelGCThreads|ConcGCThreads|CICompilerCount'

在 Linux 容器中还可以打开容器识别日志：

-Xlog:os+container=trace

如果平台资源模型比较特殊，也可以显式设置：

-XX:ActiveProcessorCount=4

老资料里经常会把 Kubernetes request、limit 与某个特定 JDK 版本的 processor count 计算方式直接绑定。这个结论不适合跨版本照抄，因为 HotSpot 对 cgroup v1/v2、quota、cpuset、shares 的处理在多个 JDK 版本里都发生过变化。升级 JDK 后最稳妥的方式始终是直接打印 JVM 实际看到的资源。

readiness、liveness 与 startupProbe 要分工

早期 Kubernetes 实践里，经常只有 readinessProbe 和 livenessProbe。今天还应该把 startupProbe 一起纳入设计。

三者职责不同：

Probe	真正应该回答的问题
startupProbe	应用是否已经完成启动，可以开始接受其他探针检查
readinessProbe	当前是否适合接收业务流量
livenessProbe	应用是否已经进入无法自行恢复、必须重启的状态

一个很危险的做法，是让 liveness 深度检查数据库、Redis、下游 HTTP 等外部依赖。下游一抖动，所有实例一起 liveness 失败并重启，反而会制造级联故障。

对于慢启动应用，更应该使用 startupProbe 保护启动阶段；readiness 可以在自身暂时过载或关键依赖不可用时把实例摘出流量；liveness 则保持轻量，只检测真正需要重启才能恢复的问题，例如线程死锁、主事件循环永久卡死等。

Pod 重建后现场会消失，所以证据必须放到 Pod 外

虚拟机上的 Java 进程死了，机器通常还在；Pod 被重新创建以后，原容器文件系统和进程现场可能已经无法访问。

因此日志和 Dump 不能只“生成”，还要确保能在 Pod 消失后拿得到。

建议至少做到：

• 应用日志、标准输出、GC 日志进入集中式日志系统；
• Heap Dump 写入持久卷或能被 sidecar/agent 上传的位置；
• 资源达到危险阈值时提前抓 Thread Dump、JFR、NMT 等现场；
• 监控记录 Pod restart count、Last State、Reason、Exit Code；
• kubectl describe pod 与事件信息进入事故时间线；
• 生产镜像如果是 distroless 或只带 JRE，准备受控的诊断镜像或 kubectl debug 临时调试容器。

JVM OOME 可以配置：

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/dump
-XX:OnOutOfMemoryError=/opt/bin/save-info.sh

但这只对 JVM 自己抛出 OOME 的场景可靠。如果进程是被容器 OOM Kill 直接 SIGKILL，JVM 没有机会执行 HeapDumpOnOutOfMemoryError 或 OnOutOfMemoryError。

同样，preStop 很适合正常下线、探针失败导致的优雅终止、流量摘除和状态保存，但如果容器已经崩溃或被直接杀死，preStop 并不保证执行。因此 OOMKilled 的关键现场不能只押在 preStop 上，必须依赖外部监控、持久化日志和提前采样。

把一套生产排障流程真正固定下来

前面的工具很多，如果没有固定流程，很容易到事故现场又变成“想到什么命令敲什么”。可以把整个过程压缩成下面这套 SOP。

第一步：先问业务症状是什么

不要从 CPU 开始，也不要从 JVM 开始。先明确：

• 哪个接口/功能失败；
• 是错误、超时还是数据异常；
• 影响范围多大；
• 从什么时候开始；
• 是否与发布、扩容、配置、流量变化重合。

第二步：先止损，再保现场

能够回滚就回滚，能够切流就切流，资源不足就先扩容，但尽量保留至少一个异常节点。事故恢复和根因分析可以并行，不要为了查根因让所有用户一直等。

第三步：按拓扑从外到内

例如：

Client
 -> CDN / LB
 -> Nginx / Gateway
 -> Ingress
 -> Service
 -> Pod
 -> Thread Pool
 -> DB / Redis / MQ

哪一层有异常，就先在那里缩小范围，而不是直接跳到某个熟悉组件。

第四步：用趋势决定抓什么快照

• CPU 高：top/pidstat -> Thread Dump / Arthas / JFR；
• Heap 增长：GC 趋势 -> Heap Dump -> MAT；
• RSS 增长但 Heap 正常：NMT -> native/线程/Direct Memory；
• SQL 慢：应用耗时 -> 连接池 -> DB 慢日志/执行计划 -> 网络；
• 网络异常：客户端、链路、服务端三段定位 -> tcpdump/Wireshark；
• Kubernetes 重启：describe / events / Last State -> OOM、probe、node、deploy 变更。

第五步：找到根因后必须验证因果

“看到一个可疑点”不等于根因。真正的根因最好能够通过下面至少一种方式验证：

• 回滚该改动，问题消失；
• 修复代码后，指标恢复；
• 压测可以稳定复现并消除；
• Heap Dump 的引用链能直接对应代码生命周期；
• Thread Stack 或 JFR 能重复捕获相同热点；
• 抓包能证明真实协议行为与预期不同。

故障复盘的产出不是文档，而是下一次更容易定位

一次故障如果只是写了“原因：数据库抖动，处理：重启服务”，价值非常低。

真正有用的复盘至少包括：

• 完整时间线；
• 影响范围；
• 根本原因与触发条件；
• 为什么监控没有更早发现；
• 为什么系统没有自动降级或隔离；
• 为什么定位花了这么久；
• 短期修复；
• 中期工程改造；
• 长期架构治理；
• 每一个 Action Item 的负责人和关闭状态。

最好的事故闭环，是下一次同类问题不再需要某个“很有经验的人”凭直觉才能处理，而是监控能够提前发现、SOP 能够快速缩小范围、工具能直接留下现场，甚至平台可以自动止损。

从写代码到做架构：工程师真正需要积累的能力

前面这些内容看起来从 Lambda 一路讲到了 Kubernetes，跨度很大，但它们其实对应了一条很清晰的成长曲线：从“会实现需求”，到“能理解程序如何运行”，再到“能让一个系统长期稳定运行”。

原课程把程序员成长总结成 28 条经验。如果从工程能力角度重新组织，可以看到几个明显阶段。

入门阶段：先让知识进入手里，而不是停在书上

对应最初的四条经验：

1. 不要长期纠结前端、后端、Java、Go、Python 的方向选择，先真正进入一个方向；
2. 真正的第一步是装 IDE、搭环境、跑出第一个程序；
3. 找有经验的人帮助确定学习主线；
4. 选择难度与当前水平匹配、能够动手实践的资料。

这几条背后的共同点是：学习必须产生反馈。 如果一直停留在阅读，没有跑过代码、没有遇到错误、没有调过环境，知识很难变成工程能力。

工作两年左右：从“会用”走向知识体系

接下来的八条更像是高级工程师真正的起点：

5. 系统学习设计模式、算法、数据库等基础；
6. 选择能让自己接触好项目、好团队的工作环境；
7. 不把成长完全寄托在公司项目上，主动学习；
8. 选择适合自己当前阶段的书；
9. 建立技术广度，理解前端、测试、运维、其他语言；
10. 建立技术深度，通过造轮子、读源码、学底层理解本质；
11. 学会高质量搜索，尤其能用英文关键词定位一手技术资料；
12. 学会画图和写文档，用输出锻炼抽象与表达。

这一阶段最重要的转变，是不再只问“这个 API 怎么用”，而开始问“为什么这样设计”“线程到底怎么跑”“数据到底怎么传”“失败时怎么证明”。这也正是从业务 CRUD 进入 JVM、网络、操作系统、架构的分水岭。

架构师阶段：技术方案必须能落地

13～16 条强调的不是更炫的技术，而是软素质、领域理解和落地能力：

• 沟通、自驱、总结能力；
• 领域经验；
• 架构必须符合团队、成本和业务现实；
• 通过口碑、分享、博客等方式建立可信赖的个人品牌。

“接地气”尤其重要。Kubernetes、Service Mesh、新数据库、新框架都可能很先进，但技术价值必须扣除迁移成本、团队学习成本、运维复杂度和长期维护成本。能稳定解决问题的朴素方案，很多时候比理念先进但团队驾驭不了的方案更好。

技术管理：产出开始通过团队完成

17～20 条从个人贡献者切换到管理者：

17. 用流程、标准、工具和自动化“管事”；
18. 招优秀的人、放权并建立工程师文化；
19. 关注前沿技术并思考真正能落地的创新；
20. 开始关注产品本身，而不是只盯技术重构。

这个阶段最典型的陷阱，是管理者仍然习惯自己解决所有疑难杂症。短期看很有安全感，长期会让自己成为团队吞吐量的上限。真正成熟的方式，是把“某个人会排障”变成“团队有监控、有工具、有 SOP、有复盘机制”。

更高层管理：技术最终要进入公司经营模型

21～24 条继续向组织层上升：

21. 搭建有梯队的团队，而不只是把人数招满；
22. 打造技术文化；
23. 提炼价值观；
24. 理解运营和财务。

到这个层级，架构决策不能只用 QPS、延迟和“技术先进性”衡量，还要理解人力、现金流、机会成本、组织能力和产品价值。

职场长期能力：把经验变成自己的方法论

最后四条是长期能力：

25. 学会工作汇报，通过双向沟通获得方向和资源；
26. 保持坚持和信念，把“我要把事情做成”作为行动目标；
27. 持续思考、复盘并沉淀方法论；
28. 和平级、跨部门同事合作时，以帮助对方解决问题的姿态建立信任。

技术成长到最后，很少是“再学一个框架”就能发生质变。更大的差异来自：能不能系统学习、能不能用证据解决问题、能不能把复杂问题讲清楚、能不能把个人经验固化成团队能力。

一份可以长期使用的 Java 工程能力地图

如果把整篇文章压缩成一张图，Java 工程师值得长期补齐的能力大致可以这样组织：

flowchart TD
    A[Java 工程能力] --> B[编码表达]
    A --> C[JVM 与并发]
    A --> D[可观测性]
    A --> E[故障诊断]
    A --> F[基础设施]
    A --> G[架构与组织]

    B --> B1[Lambda / Functional Interface]
    B --> B2[Stream / Optional]
    B --> B3[清晰的数据处理流水线]

    C --> C1[线程池 / ForkJoin]
    C --> C2[Heap / Metaspace / Native]
    C --> C3[GC / JFR]

    D --> D1[日志]
    D --> D2[Metrics]
    D --> D3[Trace]
    D --> D4[Dump / Snapshot]

    E --> E1[JDK Tools]
    E --> E2[MAT]
    E --> E3[Arthas]
    E --> E4[Wireshark]

    F --> F1[Linux]
    F --> F2[Network]
    F --> F3[Database / Middleware]
    F --> F4[Kubernetes]

    G --> G1[文档与画图]
    G --> G2[架构取舍]
    G --> G3[复盘与 SOP]
    G --> G4[团队与工程文化]

真正成熟的 Java 开发者，不只是能把功能写出来。面对一段 Stream，知道它为什么更可读，也知道并行流什么时候会把 common pool 变成风险；看到 OOM，不会第一反应就是加 -Xmx，而是先区分 Heap、Native 和容器 OOM Kill；看到 CPU 100%，能从操作系统线程一路追到 Java 方法和入参；看到 JDBC batch 很慢，会验证网络上真实发送的 SQL，而不是相信 API 名字；应用进入 Kubernetes 后，也知道 Pod、资源限制、探针和故障现场已经改变了传统 JVM 的运行边界。

这类能力很难靠一次集中学习获得。更现实的路径，是每遇到一个线上问题就多追一层：看到异常不止修代码，再看线程；看到 Heap 高不止重启，再做 Dump；看到 SQL 慢不止加索引，再看驱动、连接池和网络；看到 Pod 重启不止重新发布，再把退出原因、资源、探针和现场保留机制全部补齐。

当这些动作逐渐变成习惯，Java 就不再只是写业务代码的一门语言，而会变成一套你真正能够观察、解释、诊断和治理的生产系统。