📚 课程目录第4章现象识别第二步

现象识别第二步：用户反馈与日志中的典型错误

在周期性 Work 未清理的泄漏场景中，用户最先感知到的往往是 OutOfMemoryError 或 too many open files 两种运行时异常。这两类错误虽然表象不同，但根因可能指向同一类资源泄漏——未正确关闭或释放的 Work 对象。本阶段的目标是：从用户反馈和日志摘要中快速定位异常模式，并判定是否需要进入深层数据采集。

2.1 典型错误现象对比

错误类型	典型日志片段	用户反馈描述	与 Work 泄漏关联
OutOfMemoryError	`java.lang.OutOfMemoryError: Java heap space`	“应用运行几天后变慢，最终无响应”	Work 对象占据堆内存且未释放，GC 无法回收
too many open files	`java.io.IOException: Too many open files`	“无法新建连接、文件操作失败”	Work 对象持有没有关闭的文件句柄、Socket 或线程
OutOfMemoryError (Metaspace)	`java.lang.OutOfMemoryError: Metaspace`	“类加载器泄漏”	Work 对象通过自定义类加载器加载，引用链未断开
线程池拒绝	`RejectedExecutionException`	“任务提交失败”	Work 泄漏导致线程池活线程数持续增长，最终满负荷

2.2 故障树：从错误到泄漏根因

2.3 判断规则：哪些错误需要立即响应

快速响应触发器（满足任一即启动数据采集）：

日志中出现 OutOfMemoryError 且堆转储显示 Work 相关对象（如 com.example.worker.Work）占用超过堆 20% 以上。
Too many open files 伴随 /proc/[pid]/fd 下打开的描述符数量持续增长，且大量指向临时文件或已关闭的 Socket。
用户反馈“应用每运行 x 小时后变慢，重启后恢复正常”且监控显示堆内存或文件描述符呈阶梯状上升。

2.4 数据采集：确认泄漏的下一步

当上述判断规则命中时，需要立即进入数据采集阶段，记录关键证据：

Heap Dump：使用 jmap -dump:live,format=b,file=heap.bin <pid> 获取堆快照，重点关注 Work 对象的 GC Root 引用链。
文件描述符快照：lsof -p <pid> > fd_snapshot.txt，连续记录多个时间点，对比前后差异。
线程栈：jstack <pid> > thread_dump.txt，检查是否存在大量阻塞在 wait() 或 sleep() 的 Work 线程。
GC 日志：启动时添加 -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察 GC 频率和堆占用趋势。

⚠ 注意： 数据采集应尽可能在不对生产造成二次影响的前提下进行。Heap Dump 会暂停 JVM，建议在低峰期或备用实例上操作。

2.5 原因定位：从日志反推泄漏路径

我们通过一个典型泄漏案例来展示原因定位过程：

// 模拟泄漏的 Work 类
public class LeakyWork implements Runnable {
    private File tempFile;
    private InputStream input;
    
    public void run() {
        try {
            tempFile = File.createTempFile("work_", ".tmp");
            input = new FileInputStream(tempFile);
            // 执行业务逻辑...
            // 异常发生，直接 throw
            throw new RuntimeException("业务异常");
        } catch (Exception e) {
            // 仅打印日志，未关闭资源
            log.error("Work failed", e);
        }
        // 缺少 finally 释放
        // tempFile.deleteOnExit();  // 不释放
    }
}

运行后，每次 run() 失败都会留下一个临时文件句柄，积累后触发 Too many open files；同时 Work 对象本身也因未被移除调度队列而持续存活，导致堆内存泄漏。定位时通过 jmap -histo 可以看到大量 LeakyWork 实例。

2.6 修复动作

添加 finally 释放块：确保 close() 在异常路径也被执行。
使用 try-with-resources（Java 7+）自动关闭。
生命周期管理：Work 执行完毕后应从调度队列移除，并通知 GC。

// 修复后的 Work
public class FixedWork implements Runnable {
    public void run() {
        try (InputStream input = new FileInputStream(
                File.createTempFile("work_", ".tmp"))) {
            // 业务逻辑
        } catch (Exception e) {
            log.error("Work failed", e);
        }
        // 自动关闭，无需显式 finally
    }
}

2.7 复测验证

修复后执行以下验证步骤：

使用 strace -e file -p <pid> 监控文件打开/关闭是否配对。
重复执行 Work 任务 1000 次，观察文件描述符数量是否稳定在基线值。
触发异常场景（如模拟业务异常），确认资源正确回收。

2.8 预防体系

预防措施清单：

编码规范强制使用 try-with-resources 或 finally 释放资源。
在 Work 执行结束后增加 引用计数 或 弱引用监测，确保无残留引用。
定期执行 jmap -histo:live 并对比 Work 类实例数量，设定告警阈值。
集成 静态分析工具（如 SpotBugs）检查资源泄漏模式。