zoukankan      html  css  js  c++  java
  • 内存快照排查OOM,加密时错误方法指定provider方式错误引起的OOM

    OOM问题一般都是人工代码失误, 多数其实在review阶段应该可以排除,本文主要是想记录下内存快照排查OOM的一个过程 

    场景: 系统的交互安全完全依赖各种加密做(做到了无session,完全WEB无状态,这个设计以后可讲下),故加密变得很重要,但因为有新的加密引入了BouncyCastleProvider。故有修改,测试机一台机器上线一段时间后,运行一段时间后,系统变得非常缓慢,并到最后出现了OOM,最终产生内存快照文件。

    分析:

    JVM内存分析:观察JVM内存,发现大量OU被使用无法释放引起频发GC,导致系统缓慢(基本不可用)

    内存快照分析OOM的原因, 对于这种内存分析最好的方法是dump两份,一份正常的,一份是发生OOM时候的进行对比

    故障重现:

    首先给1G内存给Tomcat,  当OOM时输出日志, JVM参数相关配置 如下:

     -Xms1024m -Xmx1024m -Xmn512m -XX:PermSize=128m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/log/dump/ 

    正常启动后,先dump份正常的用于后面对比分析(拿OOM后产生的快照和正常的快照进行对比可以很方便找出泄漏的对象)

    文件导入Eclipse Memory Analyzer

    发现基本是Finalizer占用了内存

    说明:JAVA创建对象时,会新建一个额外的Finalizer 对象指向新创建的对象。 而回收时,至少需要经过两次GC,所以这个是正常的一个内存

    然后开始压测,2000次请求后,系统后面发现越来越慢,基本不可用了,查看GC,发现基本所有内存都满了,一直在GC

    继续说快照, 此时再把内存dump下来导入,对比

    打开快照,从全局图查看已经很明显能找到问题,内存都被JceSecurity占用了861M,可以确定是JceSecurity的问题。

    进一步分析,一般用到下面3个报表

    1, 查看全局内存

    2, 内存泄漏分析

    3, 大对象排序

    这里直接用第2个,查看泄漏分析报告

    96%的内存被JceSecurity这个类占用了

    发现问题对象后,查看Details

     显示这个类的基本情况,

    是通过GC是ROOT追溯的最短路径,这个可以追溯到问题代码的类树的结构,并找到最终引用的代码中

    可以最终找到直接引用类, 这里最终存在类 javax.crypto.jceSecurity的变量, verificationResults里面

    2, 查看verificationResults里的内容

    说明:

    with outgoning references  查看它引用了哪些内容,可以看成是 集合包含了哪些内容

    with incomming references 查看引用它的类

    说明:

    Shallow heap   是对象的自身占用大小

    Retained Heap 是对象包含内容的的总大小

    发现内存基本被它里面的一个BouncyCastleProvider占用。

    最后根据快照能得出 : 

    导致问题的地方在,类javax.crypto.jceSecurity的变量verificationResults里存的org.bouncycastle.jce.provider.BouncyCastleProvider

    代码寻找:

    根据上面找到代码中有用到org.bouncycastle.jce.provider.BouncyCastleProvider的地方,发现项目中的类CryptoUtil 

    工具类提炼出来;

     

    关键是这句,每次都new了个BouncyCastleProvider

    Cipher cipher = Cipher.getInstance(Constants.CRYPOTO_NAME, new BouncyCastleProvider());

    这个类,代码来自7u40-b43 

    从 cipher.init进去

    这段用于验证提供安全的provider对象是否是JCE可以信任的JAR,并把缓存结果存起来,将把该种provider当key存入一个静态的MAP中缓存起来, 故可以理解一到OLD区也未回收.

    verificationResults的验证

     

    值得说明的是,如果这里是HashMap而不是IdentivHashMap的话也是不会内存泄漏的,为什么这样说呢?

    如果它这用的是HashMap, 不如new多少个BouncyCastleProvider, 在HashMap中也是一个,代码证实下:

    复制代码
    /**
     * 小测试,用于说明下Provider与IdentityHashMap的分别特殊处理
     * @author 包子(何锦彬) 2017.01.20
     *
     */
    public class Test {
        public static void main(String[] args) {
            Map hashMap=new HashMap();
            hashMap.put( new BouncyCastleProvider(), "provoder1");
            hashMap.put( new BouncyCastleProvider(), "provoder2");
            System.out.println(hashMap.size()); //输出是1
            
            Map identityMap=new IdentityHashMap();
            identityMap.put( new BouncyCastleProvider(), "provoder1");
            identityMap.put( new BouncyCastleProvider(), "provoder2");
            System.out.println(identityMap.size()); //输出是2
            
        }
    }
    复制代码

     原因如下:

    1, java.security.Provider的hashCode和equals方法是有做特殊处理的,在provider中,只要密钥相等,两个Provider的比较是相等的

    2,IdentivHashMap这个类和HashMap的主要区别是,PUT时判断两个KEY是否相等用的是==

    IdentivHashMap代码如下:



    而HashMap的这里是:

    HashMap 里用的是 if (e.hash == hash && ((k = e.key) == key || key.equals(k))),比较的是hashCode与equals

    解决

    1.其实只要把指定方式由

    Cipher cipher = Cipher.getInstance(Constants.CRYPOTO_NAME, new BouncyCastleProvider());

    改成

    Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider());

    2, 把BouncyCastleProvider改成单例模式

    问1:

    至于为什么要要指定用BouncyCastleProvider 

    http://blog.csdn.net/defonds/article/details/42775183 

    就OK,或者直接删除不指定

    问2:

     其实还可以打印下存活对象, jmap -histo 7276 > dump.txt, 已经能看出些端倪

     

    持续更新留言问题,解答疑问

    最近开始总结内存方面的东西,已经总结以前遇到的一些内存案例分享下,接下来还有几篇,然后是进程/线程相关的,逐渐形成我的知识体系树

    如果你有兴趣,可以文章末尾的公众号二维码一起梳理这些信息。

    欢迎关注我的公众号,重现线上各种BUG, 一起来构建我们的知识体系

     或搜 “包子的实验室”

  • 相关阅读:
    第08组 Alpha冲刺(3/6)
    第08组 Alpha冲刺(2/6)
    第08组 Alpha冲刺(1/6)
    第08组 团队Git现场编程实战
    第08组 团队项目-需求分析报告
    网站是如何管理的
    拆机总结引发的组装指南
    计算机启动出现 Invalid Partition Table
    ARP 询问之 校级路由器的猫腻
    网络攻击形式备忘录
  • 原文地址:https://www.cnblogs.com/springsource/p/6329465.html
Copyright © 2011-2022 走看看