您好，这里是「码农镖局」51CTO博客，欢迎您来，欢迎您再来～
某新手开发工程师接到了一个保存Elasticsearch日志的任务，以供后续分析之用。但写代码的时候，误将保存日志的代码段弄成了无限循环，程序启动后，没用多久就崩溃了。
另一名工程师在动态创建类时，没有实现动态代理机制，也就没有缓存动态生成的类，导致每次都要重新生成。因此当高并发时，瞬间创建了大量的类，塞满Metaspace，内存溢出OOM。一般OOM的生产环境解决方案只有两种。一是利用Zabbix、Open-Falcon、Prometheus之类成熟的监控平台，二是自研一些简单的监控组件，例如利用hystrix的监控功能实现对系统的简单监控。较为成熟的监控体系和监控指标包括：
1、机器（资源）负载监控，如CPU使用率、磁盘使用量和剩余空间
2、内存使用量
3、网络负载
4、JVM Full GC的频率
5、业务指标，如订单量阈值、try-catch抛异常等
如果当发生OOM时需要自动dump内存快照，那么可以在JVM中加入如下参数：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/work/oom
通用的JVM模板示例：
感谢您的大驾光临！欢迎骚扰，不胜荣幸～
标签：20,监控,OOM,XX,GC,内存,JVM,系统优化 From： https://blog.51cto.com/u_15817148/6780075