背景知识 (background)
老年代的对象大多是经过多轮Young GC后晋升上来的，即对象在堆里存活的时间比较长。
老年代内存不足通常意味着内存泄露，伴随着频繁的FullGC，可能会有较大停顿，甚至停顿十几秒，导致健康检查失败或接口超时。
目前老年代内存占用超过80%且持续2分钟，则会触发报警。
查看指标 (dashboard)
其中，Old Gen(heap)即老年代内存占用 ，min 即所选时段最小值，max 为所选时段最大占用，current为当前内存。
另外，开发也应关注监控面板：GC耗时 和 GC原因与频次。
止损措施 (action)
若想保存案发现场，可临时摘流后dump内存。
若想快速恢复，去私有云/容器平台手动重启报警节点，一般重启会平滑摘流、优雅停机。
事后改进(postmortem)
老年代内存不足，大多是内存泄露，建议摘流后Dump堆内存，联系OP下载到本地MAT内存分析，及时修复。
我们整理了一些常见的原因(cause)，仅供参考。
可能的原因 (cause)
内存泄露的原因很多，大多是对象的生命周期太久了。
一、对象被长生命周期的组件引用
常见的全局静态变量、单例对象等强引用临时变量。
比如，Map每次调用Put添加对象，但缺乏淘汰机制；本地缓存没有限制最大缓存数量；ThreadLocal没有正确的清理数据；一次性加载过多数据到内存里；
在性能统计等场景使用Map时，一定要确保在任意编码习惯下的 Key / Value内存开销是可控的，比如，Druid 数据源的SQL统计，我们之前遇到过有的项目SQL语句几百KB，导致SQL统计占用过多内存。
有的项目使用OpenFeign + PathVariable/RequestParam 请求Restful接口，但指标生成时，取了动态生成的uri导致指标数量膨胀。
有的项目使用MyBatis的foreach，传递了过多的参数，导致MyBatis生成的临时大对象存在过久，不能被及时回收。
有的组件使用JVM Runtime#addShutdownHook注册钩子销毁资源，那这个对象会一直被JVM Hook引用，若创建了很多实例，则都不会被回收。
二、内存分配速率过大
可参考监控面板：GC内存分配，了解每秒钟新生代分配了多少内存、多少内存晋升到了老年代。
内存分配过大，可能是一次性加载的数据过多，通常伴随着慢请求、慢查询、不合理的报表导入导出或文件上传下载机制。
对G1来说，大对象(Humongous)会直接在老年代分配，其他GC算法也有类似机制，超过一定阈值直接晋升到老年代。
如果业务逻辑执行过久，则会导致对象不能被及时回收。
建议通过应用大盘的常用排行榜 ( HTTP慢接口/慢SQL排行 ) 或查看当时的Accesslog、应用日志来筛选可能的请求，尽可能优化代码实现，降低单次执行的资源消耗。
另外，可尝试 hawk的HeartBeat 、arthas 查看当时的线程堆栈，找到可能的慢请求。
