公司有块报警规则的模型，采用实时流storm处理技术，刚开始在规则数量和数据量小的情况下运行比较正常，但是随着业务量的增加，发现程序的运行效率越来越慢，一开始一条数据的处理时间1Ms，10天后，数据的处理性能变成8Ms，造成数据挤压，而且内存也一直递增，然后就采用传统的方案
增加并发，增加主机资源，基本上解决了数据挤压，但是运行效率越来越慢的问题一直没得到解决
9月份开始公司控运行成本，减少主机资源，主机由8C，32G缩减 8C 16G，然后遇到问题就是内存频繁报警，使用率过高，还出现过一次宕机。就出现了问题排查！
问题1：storm进程随着时间的运行越来越慢- 时间1
- 时间2
- 时间3:
问题2：JVM内存越来越大
进程内存由3G到6.7G导致主机一直资源报警
问题排查- 程序中和第三方交互资源瓶颈，比如redis，mysql等，经分析可以排除
- 程序中有大对象一直引用，无法释放，导致FullGC引起的 分析如下： jmap -dump:format=b,file=/data/heap-32.hprof 10507
jmap -dump:format=b,file=/data/heap-67.hprof 10507
分别导出进程3.2G和6.7G时的堆快照，通过jvisualvm 查看 对象大小 和线程 个数基本上一致，而且查看GC日志，很少有FullGC，基本上排除了FullGC的问题
3.难道是默认的GC回收器有问题？默认-XX:+UseParallelGC,JDK8以后推荐使用G1，可以减少程序的停顿时间，试试 -XX:+UseG1GC -XX:MaxGCPauseMillis=100,效果不明显，继续试试
4.难道是堆外内存，使用堆外内存，一部分是元数据区metaspace，可通过参数设置，触发fullGC，还有一部分是 本地方法区的内存，百度查找-XX:MaxDirectMemorySize=256m不设置也会引起内存递增，加上后也没效果，那继续分析堆快照文件，
这块引起了我的注意，jdk.nashorn.internal.runtime.scriptloaded是什么？？JDK8 引入的java中解析Js的加载器，原来程序中调用了eval,调用了 native方法导致内存增加，并且产生了很多class加载器引起的程序运行原来越慢~，那就下步验证
解决方案：每一条规则都生成一个Js function，然后缓存到本地，把变量以参数传递过去
demo如下：
然后经过包装兼容，上线运行：奇迹版的好了。
上线后的测试结果：
从原来的4毫秒左右降到了0.13毫秒 ，重点是整体资源利用率减少了50%，吞吐量提高了20倍
先写到这里。完工~
