1. 故障初现当Java应用突然消失那天凌晨三点值班手机突然响起刺耳的报警声。监控大屏上某台服务器的Java应用心跳检测全部中断。我一边用SSH连上服务器一边在心里快速排查可能性是网络抖动是应用崩溃还是更糟糕的情况输入ps -ef | grep java后发现原本应该运行的Java进程确实消失了。这时候dmesg命令成了救命稻草——这个Linux内核日志工具能告诉我们系统底层发生了什么。执行dmesg -T | grep -i kill后一行触目惊心的记录跳了出来[Fri Jul 15 03:12:47 2022] Memory cgroup out of memory: Kill process 7187 (java) score 1007 or sacrifice child这就是著名的OOM Killer在工作。Linux内核有个保护机制当系统内存严重不足时会按照进程的内存占用评分score强制终止最贪婪的进程。我们的Java应用不幸成为了牺牲品。但这里有个关键细节这条消息来自Memory cgroup子系统。这意味着我们遇到的不是普通的物理内存不足而是容器环境下的内存限制。后来查证发现这台服务器确实部署在Kubernetes集群中而应用的Pod内存上限配置只有4GB。2. 内存迷宫从GC日志到线程堆栈2.1 GC日志里的蛛丝马迹在/var/log/app目录下我们找到了GC日志文件。用grep Full GC gc.log | wc -l统计发现故障前一分钟内竟然发生了3次Full GC正常的应用Full GC频率应该以小时甚至天为单位。通过jstat -gcutil pid 1000 5实时观察GC情况发现老年代Old Gen占用率始终在95%以上。这明显是内存泄漏的典型特征——对象无法被回收不断堆积直到触发Full GC。2.2 线程堆栈里的红色警报我们用jstack -l pid thread_dump.log保存了线程快照。分析后发现两个危险信号大量线程卡在Redis连接获取http-nio-8080-exec-5 #31 daemon prio5 os_prio0 tid0x00007f48740e4800 nid0x1ce3 waiting on condition [0x00007f486b7e7000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x00000000f5d8a2b8 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at redis.clients.util.Pool.getResource(Pool.java:50)MySQL锁等待线程堆积http-nio-8080-exec-12 #38 daemon prio5 os_prio0 tid0x00007f48740e6000 nid0x1ce4 waiting on condition [0x00007f486b6e6000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x00000000f5e12300 (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:4045)3. 连锁反应从Nginx到MySQL的蝴蝶效应3.1 负载均衡的陷阱查看Nginx的access.log时发现一个异常现象所有请求都集中在宕机的这台服务器上。原来运维同学最近调整了负载均衡策略但配置有误导致流量没有均匀分配。这解释了为什么其他机器安然无恙唯独这台中奖。临时解决方案很简单upstream app_servers { server 192.168.1.1:8080 weight1; server 192.168.1.2:8080 weight1; server 192.168.1.3:8080 weight1; least_conn; # 改为最少连接算法 }3.2 Redis连接池的雪崩在应用日志中发现了大量Could not get a resource from the pool错误。检查代码发现Redis连接池配置存在严重问题Bean public JedisPool jedisPool() { // 最大连接数仅8个 return new JedisPool(new JedisPoolConfig(), redis-host, 6379); }当MySQL锁等待导致线程堆积时这些线程都持有着Redis连接不释放。连接池很快耗尽引发连锁故障。我们将配置改为spring: redis: pool: max-active: 100 max-idle: 50 min-idle: 104. 数据库深渊锁表引发的灾难4.1 那个要命的定时任务通过SHOW PROCESSLIST查看MySQL进程发现大量会话卡在同一个表t_sys_session_rec上。追踪代码发现一个定时任务每隔60秒执行全表扫描Scheduled(fixedRate 60000) public void cleanExpiredSessions() { // 没有索引的字段查询 ListSession sessions sessionMapper.selectAllWillExpireSession(); sessions.forEach(session - { session.setValid(false); sessionMapper.update(session); // 行锁升级为表锁 }); }问题出在createIp和updateTime字段没有索引导致update操作锁定了整个表。更糟的是updateTime字段上使用了函数计算SELECT * FROM t_sys_session_rec WHERE TIMESTAMPDIFF(HOUR, updateTime, NOW()) 6 -- 索引失效4.2 终极解决方案架构改造短期修复是添加索引和优化SQL但长远来看我们决定将会话数据迁移到Redis利用其自动过期特性重构定时任务为小批量处理Scheduled(fixedDelay 5000) // 改为5秒一次小批量 public void cleanSessionsInBatch() { int batchSize 100; ListLong ids sessionMapper.selectExpiredIds(batchSize); if (!ids.isEmpty()) { sessionMapper.batchInvalidate(ids); // 批量更新 } }5. 代码重构从内存杀手到性能达人5.1 HashMap的滥用现场使用jmap -dump:live,formatb,fileheap.hprof pid导出堆内存后通过VisualVM分析发现HashMap$Node和char[]是内存占用大户。检查代码发现public MapString, String getParams(HttpServletRequest request) { MapString, String params new HashMap(); // 每次调用都新建 EnumerationString names request.getParameterNames(); while (names.hasMoreElements()) { String name names.nextElement(); params.put(name, request.getParameter(name).trim()); } return params; }这个看似无害的方法在QPS 500的情况下每天会产生4300万个HashMap实例我们优化为使用静态工具类private static final ThreadLocalMapString, String PARAM_CACHE ThreadLocal.withInitial(() - new HashMap(16)); public static MapString, String getParams(HttpServletRequest request) { MapString, String params PARAM_CACHE.get(); params.clear(); // 复用Map实例 // ...填充数据逻辑不变 return params; }5.2 字符串创建的隐藏成本VisualVM中char[]的高占比让我们注意到字符串处理的低效// 反例每次调用都新建字符串 if (.equals(user.getName().trim())) { throw new BusinessException(姓名不能为空); } // 正例使用常量 if (StringUtils.isBlank(user.getName())) { throw new BusinessException(姓名不能为空); }我们使用-XX:PrintStringTableStatistics参数验证发现字符串常量池中存在大量重复值。通过引入String.intern()和预编译正则表达式减少了30%的char[]分配。6. 防御性编程构建弹性系统6.1 资源限制的自我保护在容器环境中我们学会了尊重cgroup限制# 在JVM启动参数中添加 -XX:UseContainerSupport -XX:MaxRAMPercentage75.0 # 预留25%给系统6.2 监控体系的完善我们建立了多层次的监控系统层dmesg -w监控OOM事件JVM层通过Micrometer暴露GC指标应用层关键接口的耗时和QPS监控数据库慢查询和锁等待监控// 示例通过AOP监控Redis调用 Around(execution(* org.springframework.data.redis.core.*.*(..))) public Object monitorRedis(ProceedingJoinPoint pjp) { long start System.nanoTime(); try { return pjp.proceed(); } finally { long cost System.nanoTime() - start; metrics.recordRedisCall(pjp.getSignature().getName(), cost); } }这次故障排查就像一场技术侦探游戏从Memory cgroup的OOM Killer开始一路追踪到Nginx配置、Redis连接池、MySQL锁表最终发现代码层面的根本问题。最大的收获不是解决了具体问题而是建立了一套完整的性能分析和优化方法论。现在我们的系统不仅稳定运行还能在资源达到阈值时主动降级保护——这才是工程师最该构建的系统韧性。