为什么你的应用OOM？jstack告诉你哪些线程正在偷偷吃光内存

第一章：为什么你的应用OOM？jstack告诉你哪些线程正在偷偷吃光内存

如何使用jstack捕获线程堆栈

# 查找Java进程ID
jps -l

# 生成线程堆栈快照
jstack <pid> > thread_dump.log

识别可疑线程的关键特征

• 处于 RUNNABLE 状态且持续执行循环逻辑的线程
• 持有大量对象引用或频繁调用 new 操作的方法栈
• 线程名异常或数量远超预期的线程组（如自定义线程池泄漏）

结合堆栈分析内存消耗模式

public void cacheData(String data) {
    // 将数据添加到静态集合，未设置过期机制
    DataCache.ALL_DATA.add(data); // 可能导致内存累积
}

第二章：深入理解jstack与线程内存行为

2.1 jstack工具原理与线程快照获取机制

线程快照的生成过程

jstack -l 12345 > thread_dump.txt

内部通信机制

1. 启动 AttachService 并连接目标 JVM 的套接字接口；
2. 发送“ThreadDump”指令；
3. 接收结构化文本响应并输出至控制台。

2.2 线程状态分类及其对内存占用的影响

线程的主要状态

• 就绪/运行：线程正在CPU上执行或等待调度，占用完整线程栈（通常1MB以上）；
• 阻塞/等待：因I/O或同步锁暂停，仍驻留内存，但不参与调度；
• 终止：线程逻辑结束，JVM需延迟释放其内存资源。

内存影响对比

// 示例：创建并启动线程观察状态变化
Thread thread = new Thread(() -> {
    try {
        Thread.sleep(1000); // 阻塞状态
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
});
System.out.println(thread.getState()); // NEW
thread.start();
System.out.println(thread.getState()); // RUNNABLE（可能）

2.3 如何通过线程栈识别潜在的内存泄漏源头

关键步骤解析

• 捕获运行时线程栈快照
• 识别频繁出现或异常增长的对象引用链
• 结合堆转储（Heap Dump）定位具体实例

示例：Java 线程栈中的可疑引用

Thread-0 (RUNNABLE)
  at com.example.CacheService.put(CacheService.java:45)
  at com.example.DataLoader.load(DataLoader.java:32)
  // 此处持有一个静态缓存引用，可能导致内存泄漏

常见泄漏模式对照表

2.4 实战：使用jstack捕获高内存场景下的线程堆栈

操作步骤

1. 使用jps查找目标Java进程ID
2. 执行jstack <pid>输出堆栈信息
3. 重点关注WAITING、BLOCKED状态线程

jstack 12345 > thread_dump.log

结合内存分析定位根因

2.5 分析输出：定位持续增长的调用栈与异常线程

关键线程堆栈采样

// 示例：从线程转储中提取的异常增长调用栈
Thread [Worker-Pool-Thread-3] (RUNNABLE):
    at com.example.service.DataProcessor.process(DataProcessor.java:124)
    at com.example.service.DataProcessor.lambda$submitTask$0(DataProcessor.java:88)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at java.util.concurrent.FutureTask.run(FutureTask.java:264)

异常线程分类统计

第三章：常见导致内存溢出的线程模式

3.1 死锁线程与资源等待导致的内存堆积

典型死锁场景示例

synchronized (resourceA) {
    // 持有 resourceA
    Thread.sleep(100);
    synchronized (resourceB) {  // 等待 resourceB
        // 执行操作
    }
}

资源等待对内存的影响

• 阻塞线程保留栈帧和局部变量，增加堆内存压力
• 等待期间创建的临时对象延迟回收
• 线程本地存储（ThreadLocal）未清理将导致内存泄漏

3.2 无限循环或递归调用引发的栈内存耗尽

典型递归错误示例

func badRecursion(n int) {
    fmt.Println(n)
    badRecursion(n + 1) // 缺少退出条件
}

预防措施与优化策略

• 确保每个递归函数包含明确的终止条件
• 优先使用迭代替代深层递归以降低栈压力
• 合理控制递归深度，必要时引入记忆化技术减少重复调用

3.3 线程局部变量（ThreadLocal）滥用造成的内存泄露

ThreadLocal 的基本机制

内存泄露的根本原因

• ThreadLocal 使用不当常见于 Web 应用中请求结束后未调用 remove()
• 线程复用加剧了该问题，value 长期驻留内存

private static final ThreadLocal<String> context = new ThreadLocal<>();

public void process() {
    context.set("long-running-data");
    try {
        // 业务逻辑
    } finally {
        context.remove(); // 必须手动清除，防止内存泄露
    }
}

# 获取线程dump
jstack -l <pid> > thread_dump.log

# 获取堆转储
jmap -dump:format=b,file=heap.hprof <pid>

public void processData() {
    List<Object> cache = new ArrayList<>();
    while (true) {
        cache.add(new LargeObject()); // 持续添加未释放的对象
    }
}

thread --top-n-memory 5

// 模拟问题代码
public class CacheTask implements Runnable {
    private static Map<String, byte[]> cache = new ConcurrentHashMap<>();

    public void run() {
        String key = UUID.randomUUID().toString();
        cache.put(key, new byte[1024 * 1024]); // 每次放入1MB，无过期机制
    }
}

thread.setUncaughtExceptionHandler((t, e) -> {
    System.err.println("Thread " + t.getName() + " failed: " + e.getMessage());
});

executor.shutdown();
if (!executor.awaitTermination(30, TimeUnit.SECONDS)) {
    executor.shutdownNow();
}