java object多大 java对象内存模型 数组有多长（十四）内存安全 & 完结

1

此前用的分段锁，虽然现在变单线程环境了，但是桶仍然可以继续分

用一个桶到中程性能极具下降

 分桶后10个数据块耗时分布均匀

可以按实际情况一直分下去，比如100，200

 

2 一段时间后20个桶都不够了，忘记改了啥了

改成200试下，结果并没啥用，但特点是卡在同一个10万数据块，意味着性能下降是非线性的，突然就不行了。所以怀疑是run到那个地方内存满了

换一台服务器，还用200，顺利跑出来；8小时，预期内；同时，每一个数据块到结束时也在3-6分钟，预期内；半秒100条，预期内

其实不是20个桶不够了，是换了个不行的服务器

 

  

3 内存安全

3.1 跑后是否热加载的类无对象

3.2 是否局部classloader被释放，应histo后无SizeClassLoader

3.3 多次跑后是否内存gc后有增加

 

动态加载的类中有一个静态对象依赖了另一个动态加载的类（这也可能是几年前mybatis方法区内存泄漏的原因）

形成：A中的static B对象-其回收依赖于类A是否被回收-类加载器中所有类是否解引用-类B是否可回收-类A中static B对象是否已解引

这看上去是个跟外界解引的孤岛

改了之后并没用。。局部SizeClassLoader仍然不释放，不过内存没有增加（前后jmap过）

修正，多次gc可释放：

上图是8u跑小collection后立马取样，以null为parent

下图是6u跑大collection一天后取样，以当前classloader（tomcatclassloader为parent）

 再试一次

 

 

 再次修正：

即使动态加载的类中有一个静态对象依赖了另一个动态加载的类，在本地测试时，仍然可以回收，没有出现ObjectB不能回收的情况

 

（这里理论上如果SizeClassLoader非静态，则这个类作为this的一部分，不应该被回收）

 择日在线上环境再测，SizeClassLoader为static内部类，同时SizeClassLoader以null为parent（这是一个改变，不过我认为这个change不影响结果）

 

 

隔夜

 

 测试了10次，可以回收，不过过程很虐，怀疑jmap没有真正出发重量级gc收回那个孤岛

 

4

private static class BugForPrimativeDouble {
    private double aDouble;
}

用反射取得这个Field的value，得到的是一个java.util.Double对象，值是0.0

 

 

 

 

==========

结构图