当前位置: 首页 > Java > 正文

Java问答集锦(二)

1 星2 星3 星4 星5 星 (1 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share

问:java.lang.Object是接口的超类吗?

答:话说这个其实我也答不上,咨询了下@rednaxelafx,回答是java.lang.Object不是接口的超类,原因是:接口无法直接实例化,能实例化的都是非抽象类,而所有Java类的顶层类型就是java.lang.Object,所以所有Java对象都必然有java.lang.Object的方法
所以就有了这样的特殊规定,说即便是对接口调用Object上的方法也可以,在JVM内部还有专门的特殊处理来支持这个,语言和JVM内都有特殊规定。

问:java 占用的内存,在top命令就是RES么?和另外两个值VIRT 与SWAP又是怎么个关系呢?
答:top命令看到的RES是其占用的实际内存空间大小,VIRT是占用的地址空间大小,SWAP是用到了SWAP区的大小。

问:CMS GC会不会回收Direct ByteBuffer的内存
答:Direct ByteBuffer是在Java Heap外分配内存,NIO等东西里使用的比较多,但Direct ByteBuffer分配出去的内存其实也是由GC负责回收的,而不像之前一篇文章里的Unsafe是完全自行管理的,Hotspot在GC时会扫描Direct ByteBuffer对象是否有引用,如没有则同时也会回收其占用的堆外内存,但不幸的是在6u32前的版本里,CMS GC有bug会导致可能回收不掉,具体的bug id为7112034,在链接的Backport信息里,可以看到这个bug是在hotspot 20.7的版本里修复的(hotspot的版本号通过java -version的最后一行Java Hotspot Version之类的可以看到),6u32带的就是这个版本,所以6u32是会回收的。

回收不掉的情况下会造成的问题是明明已经不用了,但堆外内存仍然被消耗掉,悲惨的情况下可能会导致堆外内存耗光。

Direct ByteBuffer除了上面这个bug可能造成堆外内存耗光外,还有一种场景也可能会造成堆外内存耗光,如Direct ByteBuffer对象晋升到了Old区,那这个时候就只能等Full GC触发(CMS GC的情况下等CMS GC),因此在Direct ByteBuffer使用较多,存活时间较长的情况下,有可能会导致堆外内存耗光(因为Direct ByteBuffer本身对象所占用的空间是很小的)。

对于上面这种类型的应用,最好是在启动参数上增加-XX:MaxDirectMemorySize=x[m|g],例如-XX:MaxDirectMemorySize=500m

这个参数默认的大小是-Xmx的值(在没设置MaxDirectMemorySize参数的情况下,用jinfo -flag等方式会看到默认值是-1,但VM.maxDirectMemory这个方法里发现是-1,则会以-Xmx作为默认值),此参数的含义是当Direct ByteBuffer分配的堆外内存到达指定大小后,即触发Full GC(这段逻辑请见Bits.reserveMemory的代码),如Full GC后仍然分配不出Direct ByteBuffer需要的空间,则会报OOM错误:
java.lang.OutOfMemoryError: Direct buffer memory

因为上面所说的状况,如碰到堆外内存占用较多的场景,可以尝试强制执行Full GC(强制的方法为执行jmap -histo:live)看看,多执行一两次,如堆外内存下降的话,很有可能就是Direct ByteBuffer造成的,对于这种情况,通常加上上面的启动参数就可解决。

很多情况下,我们会看到Java进程占用的内存超过-Xmx的大小,原因就是类似Direct ByteBuffer、Unsafe、GC、编译、自己写的JNI模块等这些是需要占用堆外空间的。

本文固定链接: http://www.chepoo.com/java-problem-two.html | IT技术精华网

Java问答集锦(二):等您坐沙发呢!

发表评论