刚接手的服务，失常稳固运行了很长一段时间，在大家伙拾掇货色筹备回家过年时，忽然就抽风了。

接口失败率居高不下？

看日志！

GC overhead limit exceeded

java.lang.OutOfMemoryError：GC overhead limit exceeded

看一下 JVM 堆栈

sudo jmap - h 流量交易 eap port

eg：sudo jmap -heap 9999

很显著，是内存不够了。

我过后的第一想法就是，应该是内存透露！我的思路如下：

1、先入为主，因为之前解决过一次因内存透露导致的 JVM OOM 问题，所以过后高度狐疑内存透露。

2、导出 JVM 堆数据，剖析、定位问题。

3、fix bug，重新部署，finish!

我依照这个思路，剖析堆栈后，发现堆中有大量对象，这些对象还没来得及回收，其余线程又在申请内存，从而导致了 OOM。造成问题的间接起因是业务申请量减少了，而现有的机器资源不够用。至于间接原因，下一篇文章再详细描述。

在揭开问题的谜底后，回过头想一想，如果过后可能仔细分析一下问题，或者问题会被更快解决。

预先反思：服务曾经稳固失常运行了一段时间，且一个月内未修改代码和更新服务。如果是代码有问题，那么问题极大可能会在新代码上线后的几天内呈现。基于这一点，根本能够排除代码问题。

线上服务呈现问题，首要的工作就是尽快恢复服务可用。如果下次呈现相似问题，我会抉择流程一，而非流程二。

造成服务不可用的间接起因是服务申请量回升，而根本原因是因为上游服务负载过高，导致微服务调用超时，从而引起连锁反应。

下图出现了用户发动申请到响应实现的大抵流程。

为何应用 image base64 传输图片？

1、历史起因。

2、开发绝对简略。

该如何优化？

1、进步 feign 申请的超时工夫。

2、进步机器配置。

3、将 image base64 放到申请体中，缩小因 feign 框架对参数进行拼接带来的内存开销。