管理Java垃圾回收站的五个建议

紫魅编程 发布于 2016/09/12 22:55
阅读 424
收藏 3

【开源中国 APP 全新上线】“动弹” 回归、集成大模型对话、畅读技术报告”

【编者按】本文作者是Niv Steingarten,是Takipi 的联合创始人,热衷于编写优雅简洁的代码。作者通过对垃圾收集器的介绍和梳理,在管理垃圾回收方面提出了五个建议,降低收集器开销,帮助大家进一步提升项目性能。本文系国内 ITOM 管理平台OneAPM 工程师编译整理。
保持GC低开销最实用的建议是什么?

早有消息声称Java 9即将发布,但如今却一再推迟,其中比较值得关注的是G1(“Garbage-First”)垃圾收集器将成为HotSpot JVM的默认收集器。从串行收集器到CMS收集器,在整个生命周期中JVM已历经多代GC的实现和更新,而接下来,G1收集器将谱写新的篇章。很多小伙伴都喜欢在网上寻找教程,这种学习的精神很值得我们鼓励,但是遗憾的是很多小伙伴看完教程后都觉的一头雾水,即便是学会了也是一知半解 如果你真的想学习java你可以来这个群这个群前面是五二七,中间是四一三后面是一四四这里有技术大牛亲自指导帮助你 还有免费的直播课程学习,不需要你付出什么只需要你有一颗学习的心就可以了不是学习的就不要加了,也是浪费时间。

随着垃圾收集器的持续发展,每一代都会进行改善和提高。在串行收集器之后的并行收集器利用多核机器强大的计算能力,实现了垃圾收集多线程。而之后的CMS(Concurrent Mark-Sweep)收集器,将收集分为多个阶段执行,允许在应用线程运行同时进行大量的收集,大大降低了“stop-the-world”全局停顿的出现频率。而现在,G1在JVM上加入了大量堆和可预测的均匀停顿,有效地提升了性能。
尽管GC不断在完善,其致命弱点还是一样:多余的和不可预知的对象分配。但本文中提出了一些高效的长期实用的建议,不管你选择哪种垃圾收集器,都可以帮助你降低GC开销。

建议1:预测收集能力
所有的Java标准集合和大多数自定义的扩展实现(如Trove 和谷歌的Guava),都会使用底层数组(无论基于原始或基于对象)。数据的长度一旦分配后,数组就不可变了,所以在许多情况下,为集合增加项目可能会导致老的底层数组被删除,然后需要重新分配一个更大的数组来替代。
大多数的集合实现都尝试在集合没有被设置为预期大小时,还能对重分配过程进行优化,并降低其开销。但是,最好的结果还是在构造集合时就设置成预期大小。
让我们看一下下面这个简单的例子:
Java代码  [url=][/url]

· public static List reverse(List<? extends T> list) {  

·     List result = new ArrayList();  

·     for (int i = list.size() - 1; i >= 0; i--) {  

·         result.add(list.get(i));  

·     }  

·     return result;  

· }  
以上方法分配了一个新的数组,再将另一个列表的项目填充其中,但只能按倒序填充。
但是,难就难在如何优化增加项目到新列表这一步骤。每次添加后,该列表还需确保其底层数组有足够的空槽能装下新项目。如果能装下,它就会直接在下一个空槽中存储新项目;但如果空间不够,它就会重新分配一个底层数组,将旧数组的内容复制到新数组中,然后再添加新项目。这一过程会导致分配的多个数组都会占据内存,直到GC最后来回收。
所以,我们可以在构建时告知数组需容纳多少个项目,重构后的代码如下:
Java代码  [url=][/url]

· public static List reverse(List<? extends T> list) {  

·     List result = new ArrayList(list.size());  

·     for (int i = list.size() - 1; i >= 0; i--) {  

·         result.add(list.get(i));  

·     }  

·     return result;  

· }  

这样一来,可以保证ArrayList构造函数在最初配置时就能容纳下list.size()个项目,这意味着它不需要再在迭代中重新分配内存。
Guava的集合类则更加先进,允许我们用一个确切数量或估计值来初始化集合。
Java代码  [url=][/url]

· List result = Lists.newArrayListWithCapacity(list.size());  

· List result = Lists.newArrayListWithExpectedSize(list.size());  

第一行代码是我们知道有多少项目需要存储的情况,第二行会分配一些多余填充以适应预估误差。

建议2:直接用处理流
当处理数据流时,如从文件中读取数据或从网上下载数据,例如,我们通常可以从数据流中有所发现:
Java代码  [url=][/url]

· byte[] fileData = readFileToByteArray(new File("myfile.txt"));  
由此产生的字节数组可以被解析为XML文档、JSON对象或协议缓冲消息,来命名一些常用选项。
当处理大型或未知大小的文件时,这个想法则不适用了,因为当JVM无法分配文件大小的缓冲区时,则会出现OutOfMemoryErrors错误。
但是,即使数据大小看似能管理,当涉及到垃圾回收时,上述模式仍会造成大量开销,因为它在堆上分配了相当大的blob来容纳文件数据。
更好的处理方式是使用合适的InputStream(本例中是FileInputStream),并直接将其送到分析器,而不是提前将整个文件读到字节数组中。所有主要库会将API直接暴露给解析流,例如:
Java代码  [url=][/url]

· FileInputStream fis = new FileInputStream(fileName);  

· MyProtoBufMessage msg = MyProtoBufMessage.parseFrom(fis);  
建议3:使用不可变对象
不变性有诸多优势,但有一个优势却极少被重视,那就是不变性对垃圾回收的影响。
不可变对象是指对象一旦创建后,其字段(本例中指非原始字段)将无法被修改。例如:
Java代码  [url=][/url]

· public class ObjectPair {  

·     private final Object first;  

·     private final Object second;  

·     public ObjectPair(Object first, Object second) {  

·         this.first = first;  

·         this.second = second;  

·     }  

·     public Object getFirst() {  

·         return first;  

·     }  

·     public Object getSecond() {  

·         return second;  

·     }  

· }  实例化上面类的结果为不可变对象——所有的字段一旦标记后则不能再被修改。
不变性意味着在构造容器完成之前,由不可变容器引用的所有对象都已经创建。在GC看来:容器会和其最新的新生代保持一致。这意味着当对新生代(young generations)执行垃圾回收周期时,GC可以跳过老年代(older generations)中的不可变对象,因为它知道不可变对象不能引用新生代的任何内容。
越少对象扫描意味着需扫描的内存页越少,而越少的内存页扫描意味着GC周期越短,同时也预示着更短的GC停顿和更好的整体吞吐量。

建议4:慎用字符串连接
字符串可能是任何基于JVM的应用中最普遍的非原始数据结构。但是,其隐含重量和使用便利性使得它们成为应用内存变大的罪魁祸首。
很明显,问题不在于被内联和拘留的文字字符串,而在于字符串在运行时被分配和构建。接下来看看构建动态字符串的简单示例:
Java代码  [url=][/url]

· public static String toString(T[] array) {  

·     String result = "[";  

·     for (int i = 0; i < array.length; i++) {  

·         result += (array == array ? "this" : array);  

·         if (i < array.length - 1) {  

·             result += ", ";  

·         }  

·     }  

·     result += "]";  

·     return result;  

· }  
获取数组并返回它的字符串表示是一个很不错的方法,但这也正是对象分配的问题所在。
要看到其背后所有的语法糖并不容易,但真正的幕后场景应该是这样:
Java代码  [url=][/url]

· public static String toString(T[] array) {  

·     String result = "[";  

·     for (int i = 0; i < array.length; i++) {  

·         StringBuilder sb1 = new StringBuilder(result);  

·         sb1.append(array == array ? "this" : array);  

·         result = sb1.toString();  

·         if (i < array.length - 1) {  

·             StringBuilder sb2 = new StringBuilder(result);  

·             sb2.append(", ");  

·             result = sb2.toString();  

·         }  

·     }  

·    StringBuilder sb3 = new StringBuilder(result);  

·     sb3.append("]");  

·     result = sb3.toString();  

·     return result;  

· }  字符串是不可变的,所以在其连接时并没有被修改,而是依次分配新的字符串。此外,编译器利用标准StringBuilder类来执行的这些链接。这就导致了双重麻烦,在每次循环迭代时,我们得到(1)隐式分配临时字符串,(2)隐式分配临时的StringBuilder对象来帮助我们构建最终结果。

避免上述问题的最佳方法是明确使用StringBuilder并直接附加给它,而不是使用略幼稚的串联运算符(“+”)。所以应该是这样:
Java代码  [url=][/url]

· public static String toString(T[] array) {  

·     StringBuilder sb = new StringBuilder("[");  

·     for (int i = 0; i < array.length; i++) {  

·         sb.append(array == array ? "this" : array);  

·         if (i < array.length - 1) {  

·             sb.append(", ");  

·         }  

·     }  

·     sb.append("]");  

·     return sb.toString();  

· }  
此时,在方法开始时我们只分配了StringBuilder。从这一点来看,所有的字符串和列表项都会被添加到唯一的StringBuilder中,最终只调用一次toString方法转换成字符串,然后返回结果。

建议5:使用专门的原始集合
Java的标准库非常方便且通用,支持使用集合绑定半静态类型。例如,如果要用一组字符串(Set<String>),或一对字符串映射到字符串列表(Map<Pair, List<String>>),直接利用标准库会非常方便。
事实上,问题之所以出现是因为我们想把double类型的值放在 int 类型的list集合或map映射中。由于泛型不能调用原始集合,则可以用包装类型代替,所以放弃List<int>而使用List<Integer>更好。
但其实这非常浪费,Integer本身就是一个完备对象,由12字节的对象头和内部4字节的整数字段组合而成,加起来每个Integer对象占16个字节,这是同样大小的基类int类型长度的4倍!然而,更大的问题是所有这些Integer实际上都是垃圾回收过程中的对象实例。
为了解决这个问题,我们在Takipi 中使用优秀Trove 集合库。Trove放弃了一些(但不是全部)支持专业高效内存的原始集合的泛型。例如,不用浪费的Map,而用专门的原始集合TintDoubleMap来替代更好:
Java代码  [url=][/url]

· TIntDoubleMap map = new TIntDoubleHashMap();  

· map.put(5, 7.0);  

· map.put(-1, 9.999);  

· ...  

Trove底层实现了原始数组的使用,所以在操作集合时没有装箱(int -> Integer)或拆箱(Integer -> int)发生,因此也不会将对象存储在基类中。

结语
随着垃圾收集器不断进步,以及实时优化和JIT编译器变得更加智能,作为开发者的我们,可以越来越少地操心代码的GC友好性。尽管如此,无论G1有多先进,在提高JVM方面,我们还有许多问题需要不断探索和实践,百尺竿头仍需更进一步。

加载中
0
eechen
eechen
Java搞一个JAVA-FPM变成PHP-FPM和HHVM那样处理完请求释放资源的FastCGI运行模式就再也不用操GC的心了.
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部