『StabilityGuide』| 10+位阿里技术专家共同发起稳定性知识库开源项目

简介： 我们穿过山和大海，也见过人山人海。我们见过各类故障，也排过千雷万险。这一次，不如我们一起，开启稳定性的探索之旅。让无法解决的问题少一点点，让世界的确定性多一点点。无论是前端业务的开发者，还是后端架构的开发者，都会遇到业务稳定性的难题。

我们穿过山和大海，也见过人山人海。
我们见过各类故障，也排过千雷万险。
这一次，不如我们一起，开启稳定性的探索之旅。
让无法解决的问题少一点点，让世界的确定性多一点点。

无论是前端业务的开发者，还是后端架构的开发者，都会遇到业务稳定性的难题。但稳定性的话题涉及之广、之深，很难通过一两篇文章道清原委。因此，我们集结了多位阿里技术工程师，他们来自性能压测、故障演练、JVM、应用容器、服务框架、流量调度、监控、诊断等不同的技术领域，以更结构化的方式来打造稳定性领域的知识库，该知识库的目录将分为：

• 事前规范：代码规约、变更管控、性能压测、故障演练、风险预案、限流降级、业务隔离；
• 事中“止血”：监控、告警、异常巡检、流量调度；
• 事后诊断：系统诊断、JVM诊断、组件诊断、在线诊断、链路追踪、Root cause；

但我们也深知，仅凭阿里自身的业务场景和技术积累，很难满足各行业不同业务场景下对稳定性知识和经验获取的需求，因此，我们将以开源的方式进行共建，欢迎您将自己或所在企业在稳定性方面的实践分享给更多的人，让无法解决的问题少一点，让世界的确定性多一点：

• 开源项目名称：StabilityGuide
• 参与方式：

1. 提 issue：将您遇到的稳定性难题详细的描述出来；
2. 写文章：申领目录中的某个主题，分享您或所在企业在稳定性方面的实践；
3. 其他：您认为对『StabilityGuide』的建设有帮助的建议；

• 项目地址，点击这里！
• 钉钉交流群：23179349

欢迎在文末，写下你的留言，随机抽3位，送出纪念衫套装（ Polo 衫 & T恤，共计两件）。

以下是来自『StabilityGuide』的第一篇文章：《系统稳定性——OutOfMemoryError 常见原因及解决方法》。

当 JVM 内存严重不足时，就会抛出 java.lang.OutOfMemoryError 错误。本文总结了常见的 OOM 原因及其解决方法，如下图所示。如有遗漏或错误，欢迎补充指正。

如果对 JVM 内存模型和垃圾回收机制不熟悉，推荐阅读 《咱们从头到尾说一次 Java 垃圾回收》。

Java heap space

当堆内存（Heap Space）没有足够空间存放新创建的对象时，就会抛出 java.lang.OutOfMemoryError: Java heap space 错误（根据实际生产经验，可以对程序日志中的 OutOfMemoryError 配置关键字告警，一经发现，立即处理）。

原因分析

Java heap space 错误产生的常见原因可以分为以下几类：

• 请求创建一个超大对象，通常是一个大数组。
• 超出预期的访问量/数据量，通常是上游系统请求流量飙升，常见于各类促销/秒杀活动，可以结合业务流量指标排查是否有尖状峰值。
• 过度使用终结器（Finalizer），该对象没有立即被 GC。
• 内存泄漏（Memory Leak），大量对象引用没有释放，JVM 无法对其自动回收，常见于使用了 File 等资源没有回收。

解决方案

针对大部分情况，通常只需要通过 -Xmx 参数调高 JVM 堆内存空间即可。如果仍然没有解决，可以参考以下情况做进一步处理：

• 如果是超大对象，可以检查其合理性，比如是否一次性查询了数据库全部结果，而没有做结果数限制。
• 如果是业务峰值压力，可以考虑添加机器资源，或者做限流降级。
• 如果是内存泄漏，需要找到持有的对象，修改代码设计，比如关闭没有释放的连接。

GC overhead limit exceeded

当 Java 进程花费 98% 以上的时间执行 GC，但只恢复了不到 2% 的内存，且该动作连续重复了 5 次，就会抛出 java.lang.OutOfMemoryError:GC overhead limit exceeded 错误。简单地说，就是应用程序已经基本耗尽了所有可用内存， GC 也无法回收。

此类问题的原因与解决方案跟 Java heap space 非常类似，可以参考上文。

Permgen space

该错误表示永久代（Permanent Generation）已用满，通常是因为加载的 class 数目太多或体积太大。

原因分析

永久代存储对象主要包括以下几类：

• 加载/缓存到内存中的 class 定义，包括类的名称，字段，方法和字节码；
• 常量池；
• 对象数组/类型数组所关联的 class；
• JIT 编译器优化后的 class 信息。

PermGen 的使用量与加载到内存的 class 的数量/大小正相关。

解决方案

根据 Permgen space 报错的时机，可以采用不同的解决方案，如下所示：

• 程序启动报错，修改 -XX:MaxPermSize 启动参数，调大永久代空间。
• 应用重新部署时报错，很可能是没有应用没有重启，导致加载了多份 class 信息，只需重启 JVM 即可解决。
• 运行时报错，应用程序可能会动态创建大量 class，而这些 class 的生命周期很短暂，但是 JVM 默认不会卸载 class，可以设置 -XX:+CMSClassUnloadingEnabled 和 -XX:+UseConcMarkSweepGC 这两个参数允许 JVM 卸载 class。

如果上述方法无法解决，可以通过 jmap 命令 dump 内存对象 jmap -dump:format=b,file=dump.hprof ，然后利用 Eclipse MAT 功能逐一分析开销最大的 classloader 和重复 class。

Metaspace

JDK 1.8 使用 Metaspace 替换了永久代（Permanent Generation），该错误表示 Metaspace 已被用满，通常是因为加载的 class 数目太多或体积太大。

此类问题的原因与解决方法跟 Permgen space 非常类似，可以参考上文。需要特别注意的是调整 Metaspace 空间大小的启动参数为 -XX:MaxMetaspaceSize。

想看完整文章内容：点击这里

原文出处：阿里云大学开发者社区

作者信息：夏明，GitHub ID @StabilityMan，花名涯海，阿里云 ARMS & EagleEye 技术专家，2016 年加入阿里巴巴，一直从事链路追踪和 APM 监控诊断领域的相关工作。