码迷,mamicode.com
首页 > 编程语言 > 详细

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

时间:2018-03-13 11:07:09      阅读:251      评论:0      收藏:0      [点我收藏+]

标签:class   提升   步骤   线程   不可变对象   html   markdown   hashmap   nim   

【编者按】本文作者是Niv Steingarten,是Takipi 的联合创始人,热衷于编写优雅简洁的代码。

作者通过对垃圾收集器的介绍和梳理,在管理垃圾回收方面提出了五个建议。减少收集器开销。帮助大家进一步提升项目性能。本文系国内 ITOM 管理平台 OneAPM project师编译整理。

保持GC低开销最有用的建议是什么?

早有消息声称Java 9即将公布,但现在却一再推迟。当中比較值得关注的是G1(“Garbage-First”)垃圾收集器将成为HotSpot JVM的默认收集器。从串行收集器到CMS收集器,在整个生命周期中JVM已历经多代GC的实现和更新,而接下来。G1收集器将谱写新的篇章。

随着垃圾收集器的持续发展,每一代都会进行改善和提高。在串行收集器之后的并行收集器利用多核机器强大的计算能力,实现了垃圾收集多线程。而之后的CMS(Concurrent Mark-Sweep)收集器,将收集分为多个阶段运行。同意在应用线程运行同一时候进行大量的收集。大大减少了“stop-the-world”全局停顿的出现频率。而现在,G1在JVM上加入了大量堆和可预測的均匀停顿,有效地提升了性能。

虽然GC不断在完好,其致命弱点还是一样:多余的和不可预知的对象分配。

但本文中提出了一些高效的长期有用的建议,不管你选择哪种垃圾收集器,都能够帮助你减少GC开销。

建议1:预測收集能力

全部的Java标准集合和大多数自己定义的扩展实现(如Trove 和谷歌的Guava)。都会使用底层数组(不管基于原始或基于对象)。数据的长度一旦分配后,数组就不可变了,所以在很多情况下。为集合添加项目可能会导致老的底层数组被删除,然后须要又一次分配一个更大的数组来替代。

大多数的集合实现都尝试在集合没有被设置为预期大小时,还能对重分配过程进行优化,并减少其开销。可是,最好的结果还是在构造集合时就设置成预期大小。

让我们看一下以下这个简单的样例:

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最后来回收。

所以,我们能够在构建时告知数组需容纳多少个项目。重构后的代码例如以下:

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的集合类则更加先进,同意我们用一个确切数量或预计值来初始化集合。

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

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

建议2:直接用处理流

当处理数据流时,如从文件里读取数据或从网上下载数据。比如,我们通常能够从数据流中有所发现:

byte[] fileData = readFileToByteArray(new File("myfile.txt"));

由此产生的字节数组能够被解析为XML文档、JSON对象或协议缓冲消息,来命名一些经常使用选项。

当处理大型或未知大小的文件时。这个想法则不适用了,由于当JVM无法分配文件大小的缓冲区时,则会出现OutOfMemoryErrors错误。

可是,即使数据大小看似能管理,当涉及到垃圾回收时。上述模式仍会造成大量开销,由于它在堆上分配了相当大的blob来容纳文件数据。

更好的处理方式是使用合适的InputStream(本例中是FileInputStream),并直接将其送到分析器,而不是提前将整个文件读到字节数组中。

全部主要库会将API直接暴露给解析流。比如:

FileInputStream fis = new FileInputStream(fileName);
MyProtoBufMessage msg = MyProtoBufMessage.parseFrom(fis);

建议3:使用不可变对象

不变性有诸多优势。但有一个优势却极少被重视。那就是不变性对垃圾回收的影响。

不可变对象是指对象一旦创建后。其字段(本例中指非原始字段)将无法被改动。

比如:

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的应用中最普遍的非原始数据结构。可是,其隐含重量和使用便利性使得它们成为应用内存变大的罪魁祸首。

很明显,问题不在于被内联和拘留的文字字符串,而在于字符串在运行时被分配和构建。接下来看看构建动态字符串的简单演示样例:

public static String toString(T[] array) {

    String result = "[";

    for (int i = 0; i < array.length; i++) {
        result += (array[i] == array ?

"this" : array[i]); if (i < array.length - 1) { result += ", "; } } result += "]"; return result; }

获取数组并返回它的字符串表示是一个很不错的方法。但这也正是对象分配的问题所在。

要看到其背后全部的语法糖并不easy,但真正的幕后场景应该是这样:

public static String toString(T[] array) {

    String result = "[";

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

        StringBuilder sb1 = new StringBuilder(result);
        sb1.append(array[i] == array ?

"this" : array[i]); 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并直接附加给它。而不是使用略幼稚的串联运算符(“+”)。

所以应该是这样:

public static String toString(T[] array) {

    StringBuilder sb = new StringBuilder("[");

    for (int i = 0; i < array.length; i++) {
        sb.append(array[i] == array ? "this" : array[i]);
        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 map = new TIntDoubleHashMap();
map.put(5, 7.0);
map.put(-1, 9.999);
...

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

结语

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

(编译自:https://www.javacodegeeks.com/2015/12/5-tips-reducing-java-garbage-collection-overhead.html

OneAPM 为您提供端到端的 Java 应用性能解决方式。我们支持全部常见的 Java 框架及应用server,助您高速发现系统瓶颈,定位异常根本原因。分钟级部署。即刻体验,Java 监控从来没有如此简单。

想阅读很多其它技术文章,请訪问 OneAPM 官方技术博客

本文转自 OneAPM 官方博客

想知道很多其它关于 Java 性能优化的内容,请扫码关注下方的公众号:

技术分享图片

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

标签:class   提升   步骤   线程   不可变对象   html   markdown   hashmap   nim   

原文地址:https://www.cnblogs.com/llguanli/p/8554516.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!