1. 线上系统假死问题现象与排查思路最近我们线上系统频繁出现假死现象具体表现为部分接口响应超时但服务器CPU和内存使用率并不高。这种看起来没事但实际上不工作的状态最让人头疼。通过监控系统发现当假死发生时活跃线程数会突然飙升到接近线程池最大值之后系统吞吐量急剧下降。初步怀疑是线程阻塞问题于是按照以下步骤进行排查通过top -Hp pid查看Java进程的线程情况发现大量线程处于BLOCKED状态使用jstack pid打印线程栈发现很多线程都在等待获取Redis连接检查Redis监控发现连接池使用率经常达到100%这提示我们可能是Redis连接池配置不当导致的线程阻塞。但为了确认具体原因我们需要更深入的内存分析。提示线上系统假死时第一时间应该检查线程状态和资源等待情况这往往能快速定位问题方向。2. MAT工具基础使用与堆转储分析2.1 MAT工具安装与配置MATMemory Analyzer Tool是Eclipse基金会提供的专业内存分析工具特别适合分析Java堆转储文件。推荐以下安装方式官网下载访问Eclipse MAT官网获取最新版本国内镜像如果下载速度慢可以使用国内镜像源版本选择建议使用1.11.0及以上版本对大型堆转储文件支持更好安装后需要调整MAT的启动参数特别是分析大内存dump时-vmargs -Xmx8g -XX:UseG1GC2.2 获取堆转储文件在假死发生时我们需要获取堆内存的快照进行分析# 使用jmap生成堆转储文件 jmap -dump:formatb,fileheap.hprof pid # 如果系统已经假死可以添加live参数只dump存活对象 jmap -dump:live,formatb,fileheap.hprof pid对于生产环境建议在业务低峰期执行先摘除流量再dump做好磁盘空间监控dump文件大小约等于堆内存使用量2.3 基础分析方法使用MAT打开堆转储文件后可以按照以下步骤分析查看Leak Suspects报告MAT会自动检测可能的内存泄漏点检查Dominator Tree查看占用内存最多的对象分析Thread Overview查看线程状态和调用栈在我们的案例中MAT报告显示有超过200个线程处于WAITING状态这些线程都在org.apache.commons.pool2.impl.GenericObjectPool.borrowObject()方法上阻塞阻塞的线程持有的本地变量显示它们都在等待Jedis连接3. Jedis连接池问题深度解析3.1 连接池配置分析通过MAT分析线程栈和对象引用关系我们发现以下配置问题# 问题配置 redis.pool.maxTotal50 redis.pool.maxIdle20 redis.pool.minIdle5 redis.pool.maxWaitMillis-1 # 无限等待 redis.pool.testOnBorrowtrue关键问题点maxWaitMillis-1当连接池耗尽时线程会无限期等待而不是快速失败testOnBorrowtrue每次获取连接都进行验证增加了获取连接的时间代码中没有正确释放连接导致连接泄漏3.2 连接泄漏验证在MAT中执行以下操作验证连接泄漏打开OQL控制台查询所有Jedis实例SELECT * FROM redis.clients.jedis.Jedis检查这些Jedis实例的GC Root发现很多没有被连接池管理查看这些游离Jedis的创建栈定位到未关闭连接的代码位置3.3 线程阻塞分析通过MAT的线程分析功能我们发现阻塞线程都在GenericObjectPool.borrowObject()方法上查看GenericObjectPool实例的内部状态numActive 50等于maxTotalnumWaiters 152大量线程在等待allObjects中只有50个连接没有泄漏时应该更多这说明连接池已经完全耗尽且由于maxWait-1线程会一直等待不会超时。4. 优化方案设计与实施4.1 连接池配置优化基于分析结果我们调整了连接池配置# 优化后的配置 redis.pool.maxTotal100 # 适当调大 redis.pool.maxIdle50 redis.pool.minIdle10 redis.pool.maxWaitMillis1000 # 1秒超时 redis.pool.testOnBorrowfalse # 改为定时检测 redis.pool.testWhileIdletrue redis.pool.timeBetweenEvictionRunsMillis30000优化点说明设置合理的等待超时1秒避免线程无限等待关闭borrow时检测改为空闲检测减少获取连接的开销适当增加连接池大小但不超过Redis服务器的maxclients限制设置合理的空闲连接回收策略4.2 代码层优化使用try-with-resources确保连接关闭try (Jedis jedis jedisPool.getResource()) { // 业务代码 } // 自动关闭添加连接获取超时监控long start System.currentTimeMillis(); try (Jedis jedis jedisPool.getResource()) { long elapsed System.currentTimeMillis() - start; if (elapsed 500) { log.warn(Get jedis connection took {}ms, elapsed); } // 业务代码 }添加连接泄漏检测// 在应用关闭时检查 Runtime.getRuntime().addShutdownHook(new Thread(() - { if (jedisPool.getNumActive() 0) { log.error(Connection leak detected: {} active connections, jedisPool.getNumActive()); } }));4.3 监控体系建设添加以下监控指标连接池活跃连接数连接池等待线程数获取连接平均耗时连接获取超时次数配置告警规则当活跃连接数 maxTotal * 0.8 时告警当等待线程数 10 时告警当获取连接平均耗时 100ms 时告警添加健康检查接口GetMapping(/health/redis) public ResponseEntityString redisHealth() { try (Jedis jedis jedisPool.getResource()) { if (PONG.equals(jedis.ping())) { return ResponseEntity.ok(OK); } } catch (Exception e) { return ResponseEntity.status(503).body(Redis connection failed); } return ResponseEntity.status(503).body(Unknown error); }5. 验证与效果评估5.1 压测验证使用JMeter进行压测对比指标优化前优化后最大QPS12002500平均响应时间450ms120ms错误率15%0.1%连接获取平均耗时3000ms20ms5.2 生产环境效果上线后观察一周的数据假死现象完全消失Redis连接池使用率稳定在30-60%之间获取连接耗时P99从5s降到50ms以内系统整体吞吐量提升80%5.3 后续优化方向引入连接池动态调整机制根据负载自动调整pool size实现连接获取的熔断机制当错误率过高时快速失败添加更细粒度的连接使用统计按业务维度监控6. 经验总结与避坑指南6.1 连接池使用注意事项永远不要设置无限等待maxWait-1获取连接必须设置超时并在代码中处理超时异常确保连接在使用后正确关闭推荐try-with-resources语法合理设置连接检测策略避免每次borrow都检测6.2 MAT使用技巧分析大型堆转储时使用MAT的Keep unreachable objects选项优先检查Leak Suspects报告对可疑对象使用Path to GC Roots功能线程分析技巧关注BLOCKED和WAITING状态的线程检查线程持有的锁和等待的锁分析线程的局部变量和对象引用内存泄漏分析比较多个时间点的堆转储使用OQL查询特定类的实例检查对象的创建栈6.3 性能问题排查流程监控指标异常检测线程状态分析jstack内存分析jmap MAT资源使用分析连接池、锁等代码层问题定位优化方案设计与验证监控完善与告警设置在实际工作中我发现很多性能问题都源于资源池的配置不当。特别是当使用第三方中间件时一定要仔细了解其连接池的实现原理和配置含义。对于关键配置项如超时时间、池大小等应该通过压测确定最优值而不是直接使用默认值或随意设置。