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

电玩女神 2022-05-29 08:42 83阅读 0赞

*   *  建议1：预测手机能力
     *  建议2：直接用流处理
     *  建议3：使用不可变对象
     *  建议4：慎用字符串连接
     *  建议5：使用专门的原始集合
        
         *  结语

**保持GC低开小最使用的建议是什么**  
在即将发布的Java 9中有一个比较值得关注的是G1(“Garbage-Firse”)垃圾收集器将成为HotSpot JVM的默认收集器。从串行收集器都CMS收集器，在整个生命周期中JVM已经历经多代GC的实现和更新，而接下来，G1收集器将谱写新的篇章。

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

尽管GC在不断的完善，其致命弱点还是一样：多余的和不可预测的对象分配。但文中提出了一些高效的长期使用的建议，不管你选择哪种垃圾收集器，都可帮助你降低GC开销。

## 建议1：预测手机能力 ##

所有的Java标准集合和大多数自定义的扩展实现（如Trove和谷歌的Guava），都会使用底层数组（无论基于原始或基于对象）。数据的长度一单分配后数组就不可变了，所以在许多情况下，危机和增加项目可能会导致老的底层数组被删除，然后需要从新分配一个更大的数组来代替。

大多数的集合实现都尝试在集合没有被设置为预期大小时就设置成预期大小。

For example:

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;
    }

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

要看到其背后所有的语法糖并不容易，但真正的幕后场景应该是这样：

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），或一对字符串映射到字符串列表（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][https_www.javacodegeeks.com_2015_12_5-tips-reducing-java-garbage-collection-overhead.html]）

[https_www.javacodegeeks.com_2015_12_5-tips-reducing-java-garbage-collection-overhead.html]: https://www.javacodegeeks.com/2015/12/5-tips-reducing-java-garbage-collection-overhead.html