Lost

最近业务反馈，他们消费MQ消息的时候，延迟很大，有一分钟多的时间，收到反馈后，我马上看了下MQ整个链路的时间

问题排查

根据traceId，把消息的每个步骤的日志拉出来看了下：

（这篇文章早就想写了，但苦于一直忙项目开发，就拖到了现在）

最近有两个case对我影响比较深，

一个case

一个是帮公司某个业务排查dubbo的问题， 现象是：业务发现他们调用某一个服务的时候，总是调用不到想要的版本：比如，他们本来想调用服务A的1.0版本，但实际上总是掉到2.0版本。

最近接手公司自己的mq，梳理了整体的架构，发现broker在扩展性方面，尤其是做HA的时候，存在难以扩展的问题。于是就想，我们在做架构设计的时候，在项目还没有开始之前，怎么能够尽可能提早的发现问题，而不是到了项目成熟期，要做一些诸如HA，扩容所容，高可用的时候才发现系统的架构原来不那么灵活。

最近排查了一次业务的FullGC，顺便理一下各种GC的日志和问题，记录下来。

正常的CMSGC的日志分析

初始标记(STW initial mark)

根据GC Roots，标记出直接可达的活跃对象，这个阶段STW

最近排查了一些FullGC的问题，就顺带着把Java的GC理一下, 本文捡一些ParNewGC的内容看看。

日志内容

1
2

2017-04-13T10:56:37.593+0800: 14084483.509: [GC 14084483.509: [ParNew: 1703042K->29303K(1887488K), 0.0293770 secs] 2070605K->397097K(5033216K), 0.0297680 secs] [Times: user=0.11 sys=0.00, real=0.03 secs]

公司线上的MQ（公司自研的MQ，类似于rocketMQ）出现fgc，于是把内存dump下来后进行分析。

初步分析

通过MAT的leak suspects，快度定位到是netty ChannelOutboundBuffer$Entry有内存泄漏的问题：