1. 项目背景与问题初现做后端服务开发尤其是高并发场景下的核心服务最怕的就是线上服务“抽风”——平时跑得好好的一到业务高峰期就出现各种超时、失败。最近我就遇到了一个典型的案例我们团队负责的一个音乐核心服务暂且叫它core-service就上演了这么一出。这个服务主要提供歌曲、歌手元数据以及用户收藏夹、播放列表等资产的查询可以理解为整个音乐App的“数据中枢”。随着用户量和查询复杂度的增长这个服务开始出现一些令人头疼的内存问题。具体表现是在每天的晚高峰时段监控大盘上会零星出现一些Dubbo RPC调用超时的告警。起初量不大大家也没太在意以为是网络抖动。但后来情况逐渐恶化超时次数增多甚至开始影响前端的核心功能比如用户打开“我的收藏”页面转半天圈圈或者搜索歌手时结果出不来。这直接触动了业务的神经必须立刻解决。我们首先排除了外部依赖如数据库、缓存的问题它们的响应时间都很稳定。接着把目光投向了服务本身。登录问题机器第一件事就是看GC日志。一看吓一跳Young GCYGC平均每分钟高达12次峰值能到24次每次平均耗时327毫秒。这意味着一分钟里有接近4秒钟的时间应用线程是在暂停等待垃圾回收的更糟糕的是Full GCFGC平均每10分钟发生0.08次看似不多但每次平均耗时长达30秒。想象一下在流量洪峰时服务突然“卡住”半分钟所有请求排队超时这简直是灾难。再看机器监控CPU使用率并没有异常飙升但堆内存的曲线图却非常诡异。老年代的内存使用率图形上出现了陡峭的“锯齿峰”——内存使用急速拉升然后触发一次FGC内存被释放一部分但释放后的基线一次比一次高就像水库的水位在每次泄洪后都降不到原来的位置。很快堆内存就被占满FGC变得极其频繁但每次回收的效果却越来越差进入一种恶性循环。这几乎是指着鼻子告诉我们内存泄漏了或者有“大家伙”在持续产生并且赖在老年代不走。2. 问题分析与初步诊断思路面对GC频繁和内存异常增长我们的排查思路是分层递进的。首先要确认问题的根源确实在JVM内存而不是操作系统层面或其他资源。通过监控确认CPU、IO、网络均无瓶颈后我们锁定了堆内存。2.1 JVM参数与垃圾收集器选型分析我们服务的默认JVM参数是这样的-Xms4096M -Xmx4096M -Xmn1024M -XX:MetaspaceSize256M -Djava.security.egdfile:/dev/./urandom -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/{runuser}/logs/other这里没有显式指定垃圾收集器在JDK 8的环境下默认使用的是Parallel Scavenge (新生代) Parallel Old (老年代)组合。这个组合的特点是“吞吐量优先”。它利用多线程并行进行垃圾回收旨在最大化应用程序的吞吐量即单位时间内处理的任务数。对于后台计算密集型、批处理任务这很合适。但它的缺点是在进行垃圾回收时为了追求效率会使用更多的线程并可能进行更彻底的回收从而导致Stop-The-World (STW)的停顿时间相对较长且不那么可控。我们的core-service是什么特点呢它是一个典型的在线实时查询服务对象生命周期短绝大部分请求产生的对象如DTO、查询结果集在一次请求响应完成后就会变成垃圾。对延迟敏感用户端等待响应要求P99甚至P999的延迟都要尽可能低长时间的GC停顿会导致大量超时。吞吐量适中虽然QPS不低但并非像消息队列那样追求极致吞吐。显然默认的“吞吐量优先”收集器与我们的“低延迟”需求是背道而驰的。长时间的YGC327ms和FGC30s就是直接证据。因此JVM调优是我们的第一站目标是将收集器更换为对延迟更友好的类型。2.2 内存异常模式识别在分析监控图表时我们总结出老年代内存异常的几种典型模式这有助于快速判断问题方向内存曲线模式可能原因对应现象阶梯式上涨FGC后不回落内存泄漏。对象被无意中如全局缓存、ThreadLocal长期持有无法回收。FGC频率越来越高效果越来越差最终OOM。瞬时尖峰快速回落大对象直接进入老年代。或一次性加载大量数据如全表查询。可能突然触发FGC但之后恢复正常。锯齿状上涨基线缓慢抬高大对象或大量中等对象持续产生且存活时间超过了Young区GC的年龄阈值晋升到老年代。YGC频繁老年代缓慢被填满触发FGC。FGC后释放部分空间但很快又被填满。我们的服务表现出的正是第三种“锯齿状上涨”模式。这强烈暗示在业务高峰期有某种“大块头”数据被频繁创建并且因为体积太大或者存活时间略长躲过了Young区的多次GC最终晋升到了老年代。老年代的空间被这些“大家伙”逐渐侵占导致可用的余量越来越小进而触发更频繁的FGC。注意这里“大对象”的定义是相对的。在JVM中-XX:PretenureSizeThreshold参数可以设置对象超过多大时直接进入老年代Parallel Scavenge收集器有效。但更常见的情况是对象本身可能不大但数量极多或者因为数据结构复杂如嵌套很深的Map、List在序列化、网络传输时被组合成一个巨大的字节数组从而成为事实上的“大对象”。基于以上分析我们的优化路径清晰了先进行JVM参数调优缓解GC压力为问题排查争取时间同时必须找到并消灭那个导致内存锯齿上涨的“元凶”——大对象。3. JVM层优化实践与效果评估既然确定了默认的Parallel收集器不适合我们那么就要选择一个更优的方案。我们的目标是降低GC停顿时间特别是YGC的停顿。常见的低延迟收集器有CMS和G1。G1 (Garbage-First)JDK 9及以后的默认收集器主打可预测的停顿时间模型适合大内存6G应用。它将堆划分为多个Region能更精细地控制回收。CMS (Concurrent Mark-Sweep)JDK 8时代主流的低延迟收集器目标是减少FGC的停顿时间。它的大部分标记和清理工作是与应用线程并发进行的。考虑到我们当时还在JDK 8环境且堆内存为4G不算特别大团队对CMS更为熟悉因此决定先尝试切换到ParNew (新生代) CMS (老年代)组合。同时我们对参数做了针对性调整-Xms4096M -Xmx4096M # 堆大小保持不变避免动态调整开销 -Xmn1536M # 新生代从1G增大到1.5G -XX:MetaspaceSize256M -XX:UseConcMarkSweepGC # 启用CMS收集器 -XX:UseParNewGC # 与CMS搭配的新生代收集器通常会自动启用显式指定更明确 -XX:CMSScavengeBeforeRemark # 关键优化在CMS重新标记阶段前强制进行一次YGC -Djava.security.egdfile:/dev/./urandom -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/{runuser}/logs/other为什么这么调增大新生代 (-Xmn1536M)我们的对象大多是短命的增大新生代Young区的“仓库”容量可以让更多对象在YGC阶段就被回收掉减少它们熬过多次GC后进入老年代的机会。这是应对“短命大对象”最直接有效的方法之一。启用CMS (-UseConcMarkSweepGC)将老年代的收集方式从并行压缩Parallel Old改为并发标记清除CMS。CMS的FGC停顿时间远低于Parallel Old因为它的大部分工作初始标记、并发标记、重新标记、并发清除都是与应用线程并发或并行进行的只有初始标记和重新标记两个阶段需要短暂的STW。开启-XX:CMSScavengeBeforeRemark这是CMS调优的一个经典参数。CMS的“重新标记”阶段需要扫描整个新生代作为“根”因为新生代的对象可能引用老年代对象。如果新生代里有很多对象这个阶段就会很慢。在重新标记前强制做一次YGC可以清空大部分新生代垃圾极大缩短重新标记的扫描时间从而降低这次STW的停顿。优化效果参数调整上线后效果是立竿见影的。从监控图上看堆内存的使用曲线变得平缓了许多老年代的内存使用率显著下降那个令人心惊胆战的“锯齿”幅度变小了。YGC的频率和平均耗时也有所改善。但是Dubbo的超时告警并没有完全消失只是在高峰期出现的频率降低了。这印证了我们之前的第二个推断JVM调优只是“治标”缓解了症状但那个周期性产生、导致内存尖峰的“大对象”根源还在。它依然会在某个时间点被创建出来可能因为新生代变大它存活得更久一点才进入老年代但最终还是会引发问题。4. 应急策略构建快速故障转移机制在定位和修复“大对象”根源的同时我们不能坐视线上业务持续受损。每次内存吃紧导致超时都需要人工介入重启机器响应慢且影响用户体验。我们需要一个自动化的应急机制能在问题发生时快速将故障机器从服务集群中隔离。我们的架构是多个api-service消费者通过Dubbo调用多个core-service提供者。思路是当某个core-service实例出现内存异常时让调用它的api-service能够自动将其“屏蔽”不再向其发送请求。实现方案异常上报在api-service的Dubbo调用侧捕获调用异常如超时、业务异常。一旦发生就将被调用的core-service的IP地址上报到一个统一的监控平台我们用的是内部基于Prometheus Alertmanager的体系。监控告警在监控平台上配置一条规则如果某个IP在短时间内被上报异常的次数超过阈值如5分钟10次则触发告警。告警回调与故障剔除这是关键步骤。告警触发后不能只发邮件需要执行一个“回调函数”。我们写了一个简单的HTTP服务接收告警平台推送过来的故障IP然后将这个IP通知给所有的api-service实例。自定义负载均衡在api-service端我们实现了一个自定义的DubboLoadBalance。它继承自AbstractLoadBalance在选择服务提供者时会先检查一个本地的“故障IP名单”。如果某个提供者的IP在这个名单里就直接跳过它选择其他健康的实例。这个名单由第三步的回调服务来更新。整个流程形成了一个闭环调用异常 - 上报IP - 监控统计 - 触发告警 - 回调通知 - 更新黑名单 - 负载均衡跳过。这样一旦某个core-service实例开始“发病”几分钟内它就会被自动从服务发现中软剔除直到人工修复后重启其IP才会从名单中移除。实操心得这个故障转移策略实现起来并不复杂但效果极佳。它相当于给系统加了一个“自动熔断器”。需要注意的是故障IP名单的维护要有过期机制比如30分钟自动清除防止因网络抖动等临时问题导致机器被永久隔离。同时回调接口要保证高可用防止成为单点。5. 深挖根源定位与优化具体的大对象有了故障转移兜底我们可以更从容地“解剖”问题机器找出大对象。我们的武器主要是线程Dump和堆内存Dump。5.1 从线程堆栈发现线索我们在业务高峰期对问题节点的JVM进程执行了jstack命令获取线程快照。在密密麻麻的线程信息中我们发现了大量状态为RUNNABLE且堆栈相似的线程dubbo-xxx-thread-1 #5612 prio5 os_prio0 tid0x00007f8e1c0b8000 nid0x4a3e runnable [0x00007f8dffefc000] java.lang.Thread.State: RUNNABLE at org.apache.dubbo.remoting.exchange.codec.ExchangeCodec.encodeResponse(ExchangeCodec.java:282) at org.apache.dubbo.remoting.exchange.codec.ExchangeCodec.encode(ExchangeCodec.java:73) at org.apache.dubbo.rpc.protocol.dubbo.DubboCountCodec.encode(DubboCountCodec.java:40) at org.apache.dubbo.remoting.transport.netty4.NettyCodecAdapter$InternalEncoder.encode(NettyCodecAdapter.java:69) at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107) ...这些线程都卡在DubboCountCodec.encode-ExchangeCodec.encodeResponse-Netty编码写入缓冲区的环节。RUNNABLE状态说明线程正在执行没有死锁但在这个位置“停留”了很长时间。这强烈暗示它们正在处理一个非常耗时的工作——序列化并写入一个庞大的响应对象。这正好解释了之前的监控现象大对象在网络序列化时耗时极长导致处理线程被占用进而引起上游调用超时。同时因为这个大对象存活时间正在被序列化、传输超过了预期导致它无法被及时回收晋升到老年代引发了FGC。5.2 堆内存分析锁定目标线程堆栈指明了方向接下来就需要用“内存显微镜”看看这个大家伙到底是谁。我们使用jmap -dump:live,formatb,fileheap.hprof pid命令在内存使用率较高时导出了一份堆转储文件。然后用MATMemory Analyzer Tool或JProfiler等工具打开这个.hprof文件。分析流程如下概览首先看支配树或大对象直方图。我们一眼就发现了一个巨大的byte[]数组占用了超过200MB的内存。溯源右键点击这个byte[]选择“Path To GC Roots”或“Merge Shortest Paths to GC Roots”排除软/弱/虚引用。最终发现这个字节数组被一个ChannelOutboundBuffer对象持有而它属于Netty的写缓冲区队列。定位业务内容进一步展开在对象引用链中我们找到了关键的Response对象。在它的属性里看到了mResult字段里面封装的就是我们的业务返回数据。MAT可以显示这个对象的摘要我们看到了类似ArrayListSongDTO这样的结构并且数量极大。找到调用方更幸运的是在Dubbo的Response对象中通常会有attachment信息或者从调用上下文可以反推出调用的服务和方法名。我们在内存快照中发现了类似com.xxx.MusicService:1.0.0::getUserFavoriteSongs的接口信息。真相大白某个查询用户收藏夹全部歌曲的接口在用户收藏量极大比如上万首时没有做分页一次性查询并返回了所有数据。每个SongDTO对象包含歌曲ID、名称、歌手、专辑、封面URL等多个字段序列化成字节流后一个响应就轻松超过了10MB。在高峰期并发几个这样的请求Netty的发送队列就被塞满内存瞬间被打高。5.3 优化措施与效果找到根因后优化就相对明确了接口改造为getUserFavoriteSongs接口增加分页参数pageNum,pageSize。这是最根本的解决方案。数据裁剪评估返回的SongDTO字段是否都是前端必需的。例如在列表页可能不需要专辑的详细描述、版权信息等可以设计一个精简版的SongSimpleDTO。缓存策略对于用户收藏夹这种读多写少的数据考虑在服务端或客户端进行缓存避免每次请求都穿透到数据库并构造大量对象。异步加载前端可以改为滚动加载每次只请求一页数据。我们优先实施了第1点和第2点。优化上线后再次观察GC监控效果非常显著YGC全天总次数下降了76.5%高峰期的累计耗时下降了75.5%。FGC从几乎每天发生变为三天才发生一次且每次耗时下降了90.1%。业务异常因内部超时导致的业务失败请求数下降了超过95%。6. 长治久安实现无侵入式大对象监控虽然优化了已知接口但难保未来不会有其他接口因为业务迭代而产生新的大对象。我们不能每次都等到线上告警了再被动地去抓Dump分析。我们需要一个主动的、常态化的监控手段能在对象大小超过阈值时就及时告警并记录现场信息。灵感来源于Dubbo源码我们在阅读Dubbo网络层编码源码ExchangeCodec.encodeResponse时发现了一段关键逻辑protected void encodeResponse(Channel channel, ChannelBuffer buffer, Response res) throws IOException { // ... 编码 ... try { checkPayload(channel, len); // 检查负载是否超过payload限制 } catch (Throwable t) { buffer.writerIndex(savedWriteIndex); // 重置缓冲区写指针 Response r new Response(res.getId(), res.getVersion()); r.setStatus(Response.BAD_RESPONSE); if (t instanceof ExceedPayloadLimitException) { r.setErrorMessage(t.getMessage()); channel.send(r); // 发送一个错误响应回去 return; } // ... 其他异常处理 } // ... 正常发送编码后的响应 ... }Dubbo自身有一个payload检查机制默认8M如果响应序列化后的大小超过这个限制会抛出ExceedPayloadLimitException。此时它会做两件事重置缓冲区之前写入的巨大会被丢弃。构造一个只包含错误信息的空Response发回给调用方。这里存在一个监控盲点当异常发生时原始的、包含巨大业务数据的Response对象已经被丢弃了。我们只能知道“有个响应太大了”但不知道是哪个接口、什么参数导致的这给排查带来了困难。我们的解决方案自定义一个Dubbo的编解码器对编码过程进行“切面”监控。核心目标是既要监控大小超过预警阈值比如5M的对象并记录详情又要能捕获那些超过payload限制8M而被Dubbo丢弃的请求信息。我们实现了一个MusicDubboCountCodec实现了Codec2接口并包装了原有的编解码器。核心逻辑在encode方法中public class MusicDubboCountCodec implements Codec2 { private static final CacheLong, String EXCEED_PAYLOAD_CACHE Caffeine.newBuilder() .maximumSize(100) .expireAfterWrite(300, TimeUnit.SECONDS) .softValues() .build(); private static final long WARNING_THRESHOLD 5 * 1024 * 1024; // 5MB预警阈值 Override public void encode(Channel channel, ChannelBuffer buffer, Object message) throws IOException { // 1. 记录编码前的位置 int before buffer.writerIndex(); // 2. 调用原始编码器 originalCodec.encode(channel, buffer, message); // 3. 检查是否为超限后重新发送的空响应并缓存其ID checkAndCacheExceedPayloadResponse(message); // 4. 计算编码后大小 int after buffer.writerIndex(); int encodedSize after - before; // 5. 超过预警阈值记录日志包含接口、方法、参数等 if (encodedSize WARNING_THRESHOLD) { log.warn([DUBBO_BIG_OBJECT] size{}, interface{}, method{}, args{}, encodedSize, getInterface(message), getMethod(message), getArgs(message)); } } private void checkAndCacheExceedPayloadResponse(Object message) { if (!(message instanceof Response)) return; Response resp (Response) message; // 情况A识别Dubbo因超限重新发送的空响应 if (resp.getStatus() Response.BAD_RESPONSE resp.getErrorMessage().contains(Data length too large)) { EXCEED_PAYLOAD_CACHE.put(resp.getId(), EXCEED_PAYLOAD); } // 情况B原始请求的响应正在编码检查其ID是否在缓存中即它曾超限 if (resp.getStatus() Response.OK EXCEED_PAYLOAD_CACHE.getIfPresent(resp.getId()) ! null) { // 此时可以安全地记录原始请求的详细信息因为它是正常编码流程 log.error([DUBBO_BIG_OBJECT_EXCEEDED] Response ID {} exceeded payload limit. Details: {}, resp.getId(), extractDetail(resp)); } } }这个设计巧妙地解决了“超限请求信息丢失”的难题对于超过预警阈值但未超payload的请求在步骤5直接计算大小并打印日志此时完整的响应信息还在message对象里可以轻松获取调用详情。对于超过payload的请求Dubbo的原始编码器会抛出异常重置buffer并生成一个新的空错误响应。这个空响应会再次经过我们的encode方法。第一次进入原始响应执行到步骤2时Dubbo内部抛出异常跳转到异常处理不会执行我们的步骤3和5。第二次进入新的空响应checkAndCacheExceedPayloadResponse方法识别出这是一个状态为BAD_RESPONSE且错误信息包含超限提示的响应于是将它的ID记录到本地缓存EXCEED_PAYLOAD_CACHE。但是原始的那个大响应对象去哪了它其实还在调用栈中只是没有被成功编码发送。当Dubbo在异常处理中完成空响应的发送后原始请求的处理流程结束。然而我们巧妙地利用了一个事实在某些场景或版本中原始的大Response对象可能依然存在并被后续处理不这里需要更精确的解释。更准确的原理是我们的监控逻辑依赖于对编码过程的包装。当一个大到触发ExceedPayloadLimitException的响应出现时原始编码流程失败originalCodec.encode(...)内部调用ExchangeCodec.encodeResponse触发checkPayload异常。此时我们的encode方法中after的计算可能因异常而不可靠但这不是重点。Dubbo的异常处理流程ExchangeCodec.encodeResponse捕获异常重置buffer创建空响应r。空响应编码流程成功Dubbo会调用channel.send(r)来发送这个空响应。这个send操作会再次触发编码流程即再次进入我们的MusicDubboCountCodec.encode()方法。缓存ID在这次对空响应的编码中checkAndCacheExceedPayloadResponse方法识别出它是BAD_RESPONSE并缓存其ID。关键点这个空响应r的id和原始大响应res的id是相同的参见源码new Response(res.getId(), ...)。因此我们缓存的是原始请求的ID。如何记录原始信息我们无法在空响应里拿到原始请求的详情。但是我们可以在下一次、同一个请求ID的正常响应如果重试成功或者通过其他旁路如全局请求上下文拦截器来关联信息。然而一个更实用的简化方案是我们主要监控预警阈值如5M。如果一个响应大小在5M到8M之间它不会触发Dubbo的异常我们的步骤5会直接记录它。如果一个响应超过8M它会被Dubbo拦截并返回空此时我们至少通过缓存ID知道“某个ID的请求曾超限”再结合业务日志需记录请求ID进行关联排查虽然不如直接打印方便但已大大缩小了排查范围。我们将这个自定义的MusicDubboCountCodec配置到Dubbo的协议中。上线后日志系统里开始定期出现[DUBBO_BIG_OBJECT]的警告。这成为了我们监控大对象产出的“火眼金睛”一旦发现就可以在业务低峰期主动联系相关开发进行优化将问题扼杀在摇篮里。7. 总结与延伸思考回顾这次从问题发现到彻底解决并建立防护体系的整个过程可以总结出处理JVM内存与大对象问题的几个关键要点监控先行指标驱动没有监控优化就是盲人摸象。必须建立完善的APM监控涵盖GC频率/耗时、堆内存各区域使用率、接口RT与QPS。当多个指标GC耗时上升、内存锯齿上涨、接口超时增加同时出现异常时基本可以锁定是内存问题。调优是组合拳需对症下药JVM参数调优不是玄学。首先要理解业务特征低延迟还是高吞吐对象生命周期长短然后根据特征选择合适的垃圾收集器如CMS/G1 for 低延迟并调整关键参数如新生代大小、CMSScavengeBeforeRemark。调优后必须对比监控数据验证效果。根因排查工具链要熟练jstack看线程锁、jmap/jcmd抓堆快照、MAT/JProfiler分析内存泄漏这是Java工程师的必修课。分析时要有假设和推理沿着引用链顺藤摸瓜。应急机制必不可少在复杂的分布式系统中单点故障难免。设计快速的故障自动隔离机制如基于负载均衡的故障转移能最大程度保证系统整体可用性为问题修复争取时间。主动防御优于被动救火通过Hook或AOP等手段实现无侵入或低侵入的监控对潜在风险如大对象、慢SQL进行实时告警。这能将运维模式从“响应式”变为“主动式”。优化是持续过程内存优化不仅仅是JVM参数。本次案例的最终解决靠的是业务代码的优化接口分页、数据裁剪。此外合理使用缓存减少对象创建、优化数据结构避免多层嵌套、检查第三方库的内存使用如序列化工具都是需要持续关注的方向。最后一点个人体会处理线上性能问题就像医生看病需要“望闻问切”。“望”监控图表“闻”日志告警“问”业务场景“切”代码与内存。最重要的是建立一套从监控、告警、诊断到修复、预防的完整闭环体系让系统具备更强的可观测性和自愈能力。这次对大对象的监控实践就是我们向这个目标迈进的一步。
从Dubbo超时到内存锯齿：高并发服务JVM调优与大对象排查实战
1. 项目背景与问题初现做后端服务开发尤其是高并发场景下的核心服务最怕的就是线上服务“抽风”——平时跑得好好的一到业务高峰期就出现各种超时、失败。最近我就遇到了一个典型的案例我们团队负责的一个音乐核心服务暂且叫它core-service就上演了这么一出。这个服务主要提供歌曲、歌手元数据以及用户收藏夹、播放列表等资产的查询可以理解为整个音乐App的“数据中枢”。随着用户量和查询复杂度的增长这个服务开始出现一些令人头疼的内存问题。具体表现是在每天的晚高峰时段监控大盘上会零星出现一些Dubbo RPC调用超时的告警。起初量不大大家也没太在意以为是网络抖动。但后来情况逐渐恶化超时次数增多甚至开始影响前端的核心功能比如用户打开“我的收藏”页面转半天圈圈或者搜索歌手时结果出不来。这直接触动了业务的神经必须立刻解决。我们首先排除了外部依赖如数据库、缓存的问题它们的响应时间都很稳定。接着把目光投向了服务本身。登录问题机器第一件事就是看GC日志。一看吓一跳Young GCYGC平均每分钟高达12次峰值能到24次每次平均耗时327毫秒。这意味着一分钟里有接近4秒钟的时间应用线程是在暂停等待垃圾回收的更糟糕的是Full GCFGC平均每10分钟发生0.08次看似不多但每次平均耗时长达30秒。想象一下在流量洪峰时服务突然“卡住”半分钟所有请求排队超时这简直是灾难。再看机器监控CPU使用率并没有异常飙升但堆内存的曲线图却非常诡异。老年代的内存使用率图形上出现了陡峭的“锯齿峰”——内存使用急速拉升然后触发一次FGC内存被释放一部分但释放后的基线一次比一次高就像水库的水位在每次泄洪后都降不到原来的位置。很快堆内存就被占满FGC变得极其频繁但每次回收的效果却越来越差进入一种恶性循环。这几乎是指着鼻子告诉我们内存泄漏了或者有“大家伙”在持续产生并且赖在老年代不走。2. 问题分析与初步诊断思路面对GC频繁和内存异常增长我们的排查思路是分层递进的。首先要确认问题的根源确实在JVM内存而不是操作系统层面或其他资源。通过监控确认CPU、IO、网络均无瓶颈后我们锁定了堆内存。2.1 JVM参数与垃圾收集器选型分析我们服务的默认JVM参数是这样的-Xms4096M -Xmx4096M -Xmn1024M -XX:MetaspaceSize256M -Djava.security.egdfile:/dev/./urandom -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/{runuser}/logs/other这里没有显式指定垃圾收集器在JDK 8的环境下默认使用的是Parallel Scavenge (新生代) Parallel Old (老年代)组合。这个组合的特点是“吞吐量优先”。它利用多线程并行进行垃圾回收旨在最大化应用程序的吞吐量即单位时间内处理的任务数。对于后台计算密集型、批处理任务这很合适。但它的缺点是在进行垃圾回收时为了追求效率会使用更多的线程并可能进行更彻底的回收从而导致Stop-The-World (STW)的停顿时间相对较长且不那么可控。我们的core-service是什么特点呢它是一个典型的在线实时查询服务对象生命周期短绝大部分请求产生的对象如DTO、查询结果集在一次请求响应完成后就会变成垃圾。对延迟敏感用户端等待响应要求P99甚至P999的延迟都要尽可能低长时间的GC停顿会导致大量超时。吞吐量适中虽然QPS不低但并非像消息队列那样追求极致吞吐。显然默认的“吞吐量优先”收集器与我们的“低延迟”需求是背道而驰的。长时间的YGC327ms和FGC30s就是直接证据。因此JVM调优是我们的第一站目标是将收集器更换为对延迟更友好的类型。2.2 内存异常模式识别在分析监控图表时我们总结出老年代内存异常的几种典型模式这有助于快速判断问题方向内存曲线模式可能原因对应现象阶梯式上涨FGC后不回落内存泄漏。对象被无意中如全局缓存、ThreadLocal长期持有无法回收。FGC频率越来越高效果越来越差最终OOM。瞬时尖峰快速回落大对象直接进入老年代。或一次性加载大量数据如全表查询。可能突然触发FGC但之后恢复正常。锯齿状上涨基线缓慢抬高大对象或大量中等对象持续产生且存活时间超过了Young区GC的年龄阈值晋升到老年代。YGC频繁老年代缓慢被填满触发FGC。FGC后释放部分空间但很快又被填满。我们的服务表现出的正是第三种“锯齿状上涨”模式。这强烈暗示在业务高峰期有某种“大块头”数据被频繁创建并且因为体积太大或者存活时间略长躲过了Young区的多次GC最终晋升到了老年代。老年代的空间被这些“大家伙”逐渐侵占导致可用的余量越来越小进而触发更频繁的FGC。注意这里“大对象”的定义是相对的。在JVM中-XX:PretenureSizeThreshold参数可以设置对象超过多大时直接进入老年代Parallel Scavenge收集器有效。但更常见的情况是对象本身可能不大但数量极多或者因为数据结构复杂如嵌套很深的Map、List在序列化、网络传输时被组合成一个巨大的字节数组从而成为事实上的“大对象”。基于以上分析我们的优化路径清晰了先进行JVM参数调优缓解GC压力为问题排查争取时间同时必须找到并消灭那个导致内存锯齿上涨的“元凶”——大对象。3. JVM层优化实践与效果评估既然确定了默认的Parallel收集器不适合我们那么就要选择一个更优的方案。我们的目标是降低GC停顿时间特别是YGC的停顿。常见的低延迟收集器有CMS和G1。G1 (Garbage-First)JDK 9及以后的默认收集器主打可预测的停顿时间模型适合大内存6G应用。它将堆划分为多个Region能更精细地控制回收。CMS (Concurrent Mark-Sweep)JDK 8时代主流的低延迟收集器目标是减少FGC的停顿时间。它的大部分标记和清理工作是与应用线程并发进行的。考虑到我们当时还在JDK 8环境且堆内存为4G不算特别大团队对CMS更为熟悉因此决定先尝试切换到ParNew (新生代) CMS (老年代)组合。同时我们对参数做了针对性调整-Xms4096M -Xmx4096M # 堆大小保持不变避免动态调整开销 -Xmn1536M # 新生代从1G增大到1.5G -XX:MetaspaceSize256M -XX:UseConcMarkSweepGC # 启用CMS收集器 -XX:UseParNewGC # 与CMS搭配的新生代收集器通常会自动启用显式指定更明确 -XX:CMSScavengeBeforeRemark # 关键优化在CMS重新标记阶段前强制进行一次YGC -Djava.security.egdfile:/dev/./urandom -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/{runuser}/logs/other为什么这么调增大新生代 (-Xmn1536M)我们的对象大多是短命的增大新生代Young区的“仓库”容量可以让更多对象在YGC阶段就被回收掉减少它们熬过多次GC后进入老年代的机会。这是应对“短命大对象”最直接有效的方法之一。启用CMS (-UseConcMarkSweepGC)将老年代的收集方式从并行压缩Parallel Old改为并发标记清除CMS。CMS的FGC停顿时间远低于Parallel Old因为它的大部分工作初始标记、并发标记、重新标记、并发清除都是与应用线程并发或并行进行的只有初始标记和重新标记两个阶段需要短暂的STW。开启-XX:CMSScavengeBeforeRemark这是CMS调优的一个经典参数。CMS的“重新标记”阶段需要扫描整个新生代作为“根”因为新生代的对象可能引用老年代对象。如果新生代里有很多对象这个阶段就会很慢。在重新标记前强制做一次YGC可以清空大部分新生代垃圾极大缩短重新标记的扫描时间从而降低这次STW的停顿。优化效果参数调整上线后效果是立竿见影的。从监控图上看堆内存的使用曲线变得平缓了许多老年代的内存使用率显著下降那个令人心惊胆战的“锯齿”幅度变小了。YGC的频率和平均耗时也有所改善。但是Dubbo的超时告警并没有完全消失只是在高峰期出现的频率降低了。这印证了我们之前的第二个推断JVM调优只是“治标”缓解了症状但那个周期性产生、导致内存尖峰的“大对象”根源还在。它依然会在某个时间点被创建出来可能因为新生代变大它存活得更久一点才进入老年代但最终还是会引发问题。4. 应急策略构建快速故障转移机制在定位和修复“大对象”根源的同时我们不能坐视线上业务持续受损。每次内存吃紧导致超时都需要人工介入重启机器响应慢且影响用户体验。我们需要一个自动化的应急机制能在问题发生时快速将故障机器从服务集群中隔离。我们的架构是多个api-service消费者通过Dubbo调用多个core-service提供者。思路是当某个core-service实例出现内存异常时让调用它的api-service能够自动将其“屏蔽”不再向其发送请求。实现方案异常上报在api-service的Dubbo调用侧捕获调用异常如超时、业务异常。一旦发生就将被调用的core-service的IP地址上报到一个统一的监控平台我们用的是内部基于Prometheus Alertmanager的体系。监控告警在监控平台上配置一条规则如果某个IP在短时间内被上报异常的次数超过阈值如5分钟10次则触发告警。告警回调与故障剔除这是关键步骤。告警触发后不能只发邮件需要执行一个“回调函数”。我们写了一个简单的HTTP服务接收告警平台推送过来的故障IP然后将这个IP通知给所有的api-service实例。自定义负载均衡在api-service端我们实现了一个自定义的DubboLoadBalance。它继承自AbstractLoadBalance在选择服务提供者时会先检查一个本地的“故障IP名单”。如果某个提供者的IP在这个名单里就直接跳过它选择其他健康的实例。这个名单由第三步的回调服务来更新。整个流程形成了一个闭环调用异常 - 上报IP - 监控统计 - 触发告警 - 回调通知 - 更新黑名单 - 负载均衡跳过。这样一旦某个core-service实例开始“发病”几分钟内它就会被自动从服务发现中软剔除直到人工修复后重启其IP才会从名单中移除。实操心得这个故障转移策略实现起来并不复杂但效果极佳。它相当于给系统加了一个“自动熔断器”。需要注意的是故障IP名单的维护要有过期机制比如30分钟自动清除防止因网络抖动等临时问题导致机器被永久隔离。同时回调接口要保证高可用防止成为单点。5. 深挖根源定位与优化具体的大对象有了故障转移兜底我们可以更从容地“解剖”问题机器找出大对象。我们的武器主要是线程Dump和堆内存Dump。5.1 从线程堆栈发现线索我们在业务高峰期对问题节点的JVM进程执行了jstack命令获取线程快照。在密密麻麻的线程信息中我们发现了大量状态为RUNNABLE且堆栈相似的线程dubbo-xxx-thread-1 #5612 prio5 os_prio0 tid0x00007f8e1c0b8000 nid0x4a3e runnable [0x00007f8dffefc000] java.lang.Thread.State: RUNNABLE at org.apache.dubbo.remoting.exchange.codec.ExchangeCodec.encodeResponse(ExchangeCodec.java:282) at org.apache.dubbo.remoting.exchange.codec.ExchangeCodec.encode(ExchangeCodec.java:73) at org.apache.dubbo.rpc.protocol.dubbo.DubboCountCodec.encode(DubboCountCodec.java:40) at org.apache.dubbo.remoting.transport.netty4.NettyCodecAdapter$InternalEncoder.encode(NettyCodecAdapter.java:69) at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107) ...这些线程都卡在DubboCountCodec.encode-ExchangeCodec.encodeResponse-Netty编码写入缓冲区的环节。RUNNABLE状态说明线程正在执行没有死锁但在这个位置“停留”了很长时间。这强烈暗示它们正在处理一个非常耗时的工作——序列化并写入一个庞大的响应对象。这正好解释了之前的监控现象大对象在网络序列化时耗时极长导致处理线程被占用进而引起上游调用超时。同时因为这个大对象存活时间正在被序列化、传输超过了预期导致它无法被及时回收晋升到老年代引发了FGC。5.2 堆内存分析锁定目标线程堆栈指明了方向接下来就需要用“内存显微镜”看看这个大家伙到底是谁。我们使用jmap -dump:live,formatb,fileheap.hprof pid命令在内存使用率较高时导出了一份堆转储文件。然后用MATMemory Analyzer Tool或JProfiler等工具打开这个.hprof文件。分析流程如下概览首先看支配树或大对象直方图。我们一眼就发现了一个巨大的byte[]数组占用了超过200MB的内存。溯源右键点击这个byte[]选择“Path To GC Roots”或“Merge Shortest Paths to GC Roots”排除软/弱/虚引用。最终发现这个字节数组被一个ChannelOutboundBuffer对象持有而它属于Netty的写缓冲区队列。定位业务内容进一步展开在对象引用链中我们找到了关键的Response对象。在它的属性里看到了mResult字段里面封装的就是我们的业务返回数据。MAT可以显示这个对象的摘要我们看到了类似ArrayListSongDTO这样的结构并且数量极大。找到调用方更幸运的是在Dubbo的Response对象中通常会有attachment信息或者从调用上下文可以反推出调用的服务和方法名。我们在内存快照中发现了类似com.xxx.MusicService:1.0.0::getUserFavoriteSongs的接口信息。真相大白某个查询用户收藏夹全部歌曲的接口在用户收藏量极大比如上万首时没有做分页一次性查询并返回了所有数据。每个SongDTO对象包含歌曲ID、名称、歌手、专辑、封面URL等多个字段序列化成字节流后一个响应就轻松超过了10MB。在高峰期并发几个这样的请求Netty的发送队列就被塞满内存瞬间被打高。5.3 优化措施与效果找到根因后优化就相对明确了接口改造为getUserFavoriteSongs接口增加分页参数pageNum,pageSize。这是最根本的解决方案。数据裁剪评估返回的SongDTO字段是否都是前端必需的。例如在列表页可能不需要专辑的详细描述、版权信息等可以设计一个精简版的SongSimpleDTO。缓存策略对于用户收藏夹这种读多写少的数据考虑在服务端或客户端进行缓存避免每次请求都穿透到数据库并构造大量对象。异步加载前端可以改为滚动加载每次只请求一页数据。我们优先实施了第1点和第2点。优化上线后再次观察GC监控效果非常显著YGC全天总次数下降了76.5%高峰期的累计耗时下降了75.5%。FGC从几乎每天发生变为三天才发生一次且每次耗时下降了90.1%。业务异常因内部超时导致的业务失败请求数下降了超过95%。6. 长治久安实现无侵入式大对象监控虽然优化了已知接口但难保未来不会有其他接口因为业务迭代而产生新的大对象。我们不能每次都等到线上告警了再被动地去抓Dump分析。我们需要一个主动的、常态化的监控手段能在对象大小超过阈值时就及时告警并记录现场信息。灵感来源于Dubbo源码我们在阅读Dubbo网络层编码源码ExchangeCodec.encodeResponse时发现了一段关键逻辑protected void encodeResponse(Channel channel, ChannelBuffer buffer, Response res) throws IOException { // ... 编码 ... try { checkPayload(channel, len); // 检查负载是否超过payload限制 } catch (Throwable t) { buffer.writerIndex(savedWriteIndex); // 重置缓冲区写指针 Response r new Response(res.getId(), res.getVersion()); r.setStatus(Response.BAD_RESPONSE); if (t instanceof ExceedPayloadLimitException) { r.setErrorMessage(t.getMessage()); channel.send(r); // 发送一个错误响应回去 return; } // ... 其他异常处理 } // ... 正常发送编码后的响应 ... }Dubbo自身有一个payload检查机制默认8M如果响应序列化后的大小超过这个限制会抛出ExceedPayloadLimitException。此时它会做两件事重置缓冲区之前写入的巨大会被丢弃。构造一个只包含错误信息的空Response发回给调用方。这里存在一个监控盲点当异常发生时原始的、包含巨大业务数据的Response对象已经被丢弃了。我们只能知道“有个响应太大了”但不知道是哪个接口、什么参数导致的这给排查带来了困难。我们的解决方案自定义一个Dubbo的编解码器对编码过程进行“切面”监控。核心目标是既要监控大小超过预警阈值比如5M的对象并记录详情又要能捕获那些超过payload限制8M而被Dubbo丢弃的请求信息。我们实现了一个MusicDubboCountCodec实现了Codec2接口并包装了原有的编解码器。核心逻辑在encode方法中public class MusicDubboCountCodec implements Codec2 { private static final CacheLong, String EXCEED_PAYLOAD_CACHE Caffeine.newBuilder() .maximumSize(100) .expireAfterWrite(300, TimeUnit.SECONDS) .softValues() .build(); private static final long WARNING_THRESHOLD 5 * 1024 * 1024; // 5MB预警阈值 Override public void encode(Channel channel, ChannelBuffer buffer, Object message) throws IOException { // 1. 记录编码前的位置 int before buffer.writerIndex(); // 2. 调用原始编码器 originalCodec.encode(channel, buffer, message); // 3. 检查是否为超限后重新发送的空响应并缓存其ID checkAndCacheExceedPayloadResponse(message); // 4. 计算编码后大小 int after buffer.writerIndex(); int encodedSize after - before; // 5. 超过预警阈值记录日志包含接口、方法、参数等 if (encodedSize WARNING_THRESHOLD) { log.warn([DUBBO_BIG_OBJECT] size{}, interface{}, method{}, args{}, encodedSize, getInterface(message), getMethod(message), getArgs(message)); } } private void checkAndCacheExceedPayloadResponse(Object message) { if (!(message instanceof Response)) return; Response resp (Response) message; // 情况A识别Dubbo因超限重新发送的空响应 if (resp.getStatus() Response.BAD_RESPONSE resp.getErrorMessage().contains(Data length too large)) { EXCEED_PAYLOAD_CACHE.put(resp.getId(), EXCEED_PAYLOAD); } // 情况B原始请求的响应正在编码检查其ID是否在缓存中即它曾超限 if (resp.getStatus() Response.OK EXCEED_PAYLOAD_CACHE.getIfPresent(resp.getId()) ! null) { // 此时可以安全地记录原始请求的详细信息因为它是正常编码流程 log.error([DUBBO_BIG_OBJECT_EXCEEDED] Response ID {} exceeded payload limit. Details: {}, resp.getId(), extractDetail(resp)); } } }这个设计巧妙地解决了“超限请求信息丢失”的难题对于超过预警阈值但未超payload的请求在步骤5直接计算大小并打印日志此时完整的响应信息还在message对象里可以轻松获取调用详情。对于超过payload的请求Dubbo的原始编码器会抛出异常重置buffer并生成一个新的空错误响应。这个空响应会再次经过我们的encode方法。第一次进入原始响应执行到步骤2时Dubbo内部抛出异常跳转到异常处理不会执行我们的步骤3和5。第二次进入新的空响应checkAndCacheExceedPayloadResponse方法识别出这是一个状态为BAD_RESPONSE且错误信息包含超限提示的响应于是将它的ID记录到本地缓存EXCEED_PAYLOAD_CACHE。但是原始的那个大响应对象去哪了它其实还在调用栈中只是没有被成功编码发送。当Dubbo在异常处理中完成空响应的发送后原始请求的处理流程结束。然而我们巧妙地利用了一个事实在某些场景或版本中原始的大Response对象可能依然存在并被后续处理不这里需要更精确的解释。更准确的原理是我们的监控逻辑依赖于对编码过程的包装。当一个大到触发ExceedPayloadLimitException的响应出现时原始编码流程失败originalCodec.encode(...)内部调用ExchangeCodec.encodeResponse触发checkPayload异常。此时我们的encode方法中after的计算可能因异常而不可靠但这不是重点。Dubbo的异常处理流程ExchangeCodec.encodeResponse捕获异常重置buffer创建空响应r。空响应编码流程成功Dubbo会调用channel.send(r)来发送这个空响应。这个send操作会再次触发编码流程即再次进入我们的MusicDubboCountCodec.encode()方法。缓存ID在这次对空响应的编码中checkAndCacheExceedPayloadResponse方法识别出它是BAD_RESPONSE并缓存其ID。关键点这个空响应r的id和原始大响应res的id是相同的参见源码new Response(res.getId(), ...)。因此我们缓存的是原始请求的ID。如何记录原始信息我们无法在空响应里拿到原始请求的详情。但是我们可以在下一次、同一个请求ID的正常响应如果重试成功或者通过其他旁路如全局请求上下文拦截器来关联信息。然而一个更实用的简化方案是我们主要监控预警阈值如5M。如果一个响应大小在5M到8M之间它不会触发Dubbo的异常我们的步骤5会直接记录它。如果一个响应超过8M它会被Dubbo拦截并返回空此时我们至少通过缓存ID知道“某个ID的请求曾超限”再结合业务日志需记录请求ID进行关联排查虽然不如直接打印方便但已大大缩小了排查范围。我们将这个自定义的MusicDubboCountCodec配置到Dubbo的协议中。上线后日志系统里开始定期出现[DUBBO_BIG_OBJECT]的警告。这成为了我们监控大对象产出的“火眼金睛”一旦发现就可以在业务低峰期主动联系相关开发进行优化将问题扼杀在摇篮里。7. 总结与延伸思考回顾这次从问题发现到彻底解决并建立防护体系的整个过程可以总结出处理JVM内存与大对象问题的几个关键要点监控先行指标驱动没有监控优化就是盲人摸象。必须建立完善的APM监控涵盖GC频率/耗时、堆内存各区域使用率、接口RT与QPS。当多个指标GC耗时上升、内存锯齿上涨、接口超时增加同时出现异常时基本可以锁定是内存问题。调优是组合拳需对症下药JVM参数调优不是玄学。首先要理解业务特征低延迟还是高吞吐对象生命周期长短然后根据特征选择合适的垃圾收集器如CMS/G1 for 低延迟并调整关键参数如新生代大小、CMSScavengeBeforeRemark。调优后必须对比监控数据验证效果。根因排查工具链要熟练jstack看线程锁、jmap/jcmd抓堆快照、MAT/JProfiler分析内存泄漏这是Java工程师的必修课。分析时要有假设和推理沿着引用链顺藤摸瓜。应急机制必不可少在复杂的分布式系统中单点故障难免。设计快速的故障自动隔离机制如基于负载均衡的故障转移能最大程度保证系统整体可用性为问题修复争取时间。主动防御优于被动救火通过Hook或AOP等手段实现无侵入或低侵入的监控对潜在风险如大对象、慢SQL进行实时告警。这能将运维模式从“响应式”变为“主动式”。优化是持续过程内存优化不仅仅是JVM参数。本次案例的最终解决靠的是业务代码的优化接口分页、数据裁剪。此外合理使用缓存减少对象创建、优化数据结构避免多层嵌套、检查第三方库的内存使用如序列化工具都是需要持续关注的方向。最后一点个人体会处理线上性能问题就像医生看病需要“望闻问切”。“望”监控图表“闻”日志告警“问”业务场景“切”代码与内存。最重要的是建立一套从监控、告警、诊断到修复、预防的完整闭环体系让系统具备更强的可观测性和自愈能力。这次对大对象的监控实践就是我们向这个目标迈进的一步。
