标签：pos swf 比较 自身 [] pod 导致 hashmap name
写在前面：
最近开始总结内存方面的东西，已经总结以前遇到的一些内存案例分享下，接下来还有几篇，然后是进程/线程相关的，逐渐形成我的知识体系树
如果你有兴趣，可以文章末尾的公众号二维码一起梳理这些信息。
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， 一起来构建我们的知识体系
或搜 “包子的实验室”
内存快照排查OOM，加密时错误方法指定provider方式错误引起的OOM
标签：pos swf 比较 自身 [] pod 导致 hashmap name
原文地址：http://www.cnblogs.com/springsource/p/6321846.html
