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

澳门新葡亰平台官网 1

保持GC低开销的窍门有哪些?

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

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

随着一再拖延而即将发布的 Java9,G1(“Garbage First”)垃圾回收器将被成为
HotSpot 虚拟机默认的垃圾回收器。从 serial 垃圾回收器到CMS 收集器, JVM
见证了许多 GC 实现,而 G1 将成为其下一代垃圾回收器。

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

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

随着垃圾收集器的发展,每一代 GC
与其上一代相比,都带来了巨大的进步和改善。parallel GC 与 serial GC
相比,它让垃圾收集器以多线程的方式工作,充分利用了多核计算机的计算能力。CMS(“Concurrent
Mark-Sweep”)收集器与 parallel GC
相比,它将回收过程分成了多个阶段,使得应用线程正在运行的时候,收集工作可以并发地完成,大大改善了频繁执行
“stop-the-world” 的情况。G1 对于拥有大量堆内存的 JVM
表现出更好的性能,并且具有更好的可预测和统一的暂停过程。

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

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

Tip #1: 预测集合的容量

所有标准的 Java 集合,包括定制和扩展的实现(比如 Trove 和 Google 的
Guava),底层都使用了数组(原生数据类型或者基于对象的类型)。因为数组一旦被分配,其大小就不可变,因此添加元素到集合时,大多数情况下都会导致需要重新申请一个新的大容量数组替换老的数组(指集合底层实现使用的数组)。

即使没有提供集合初始化的大小,大多数集合的实现都尽量优化重新分配数组的处理并且将其开销平摊到最低。不过,在构造集合的时候就提供大小可以得到最佳的效果。

让我们将下面的代码作为一个简单的例子分析一下:

public static List reverse(List & lt; ? extends T & gt; list) {

    List result = new ArrayList();

    for (int i = list.size() - 1; i & gt; = 0; i--) {
        result.add(list.get(i));
    }

    return result;
}

This method allocates a new array, then fills it up with items from
another list, only in reverse order.
这个方法分配了一个新的数组,然后用另一个 list
中元素对该数组进行填充,只是元素的数序发生了变化。

这个处理方式可能会付出惨重的性能代价,其优化的点在添加元素到新的 list
中这行代码。 随着每一次添加元素,list
都需要确保其底层数组拥有足够的位置来容纳新的元素。如果有空闲的位置,那么只是简单地将新元素存储到下一个空闲的槽位。如果没有的话,将分配一个新的底层数组,拷贝旧的数组内容到新的数组中,然后添加新的元素。这将导致多次分配数组,那些剩余的旧数组最终被
GC 所回收。

澳门新葡亰平台官网 ,我们可以通过在构造集合时让其底层的数组知道它将存储多少元素,从而避免这些多余的分配

public static List reverse(List & lt; ? extends T & gt; list) {

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

    for (int i = list.size() - 1; i & gt; = 0; i--) {
        result.add(list.get(i));
    }

    return result;

}

上面的代码通过 ArrayList 的构造器指定足够大的空间来存储 list.size()
个元素,在初始化时完成分配的执行,这意味着 List
在迭代的过程中无需再次分配内存。

Guava
的集合类则更进一步,允许初始化集合时明确指定期望元素的个数或者指定一个预测值。

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

上面的代码中,前者用于我们已经准确地知道集合将要存储多少元素,而后者的分配方式考虑了错误预估的情况。

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

建议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());

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

Tip #2:直接处理数据流

当处理数据流时,比如从一个文件读取数据或者从网络中下载数据,下面的代码是非常常见的:

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

所产生的字节数组可能被解析 XML 文档、JSON
对象或者协议缓冲消息,以及一些常见的可选项。

当处理大文件或者文件的大小无法预测时,上面的做法很是不明智的,因为当 JVM
无法分配一个缓冲区来处理真正文件时,就会导致OutOfMemeoryErrors。

即使数据的大小是可管理的,当到垃圾回收时,使用上面的模式依然会造成巨大的开销,因为它在堆中分配了一块非常大的区域来存储文件数据。

一种更加好的处理方式是使用合适的 InputStream (比如在这个例子中使用
FileInputStream)直接传递给解析器,不再一次性将整个文件读取到一个字节数组中。所有主流的开源库都提供相应的
API 来直接接受一个输入流进行处理,比如:

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

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

建议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);

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

}

将上面的类实例化后会产生一个不可变对象—它的所有属性用 final
修饰,构造完成后就不能改变了。

不可变性意味着所有被一个不可变容器所引用的对象,在容器构造完成前对象就已经被创建。就
GC
而言:这个容器年轻程度至少和其所持有的最年轻的引用一样。这意味着当在年轻代执行垃圾回收的过程中,GC
因为不可变对象处于老年代而跳过它们,直到确定这些不可变对象在老年代中不被任何对象所引用时,才完成对它们的回收。

更少的扫描对象意味着对内存页更少的扫描,越少的扫描内存页就意味着更短的
GC 生命周期,也意味着更短的 GC 暂停和更好的总吞吐量。

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

建议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停顿和更好的整体吞吐量。

Tip #4: 小心字符串拼接

字符串可能是在所有基于 JVM
应用程序中最常用的非原生数据结构。然而,由于其隐式地开销负担和简便的使用,非常容易成为占用大量内存的罪归祸首。

这个问题很明显不在于字符串字面值,而是在运行时分配内存初始化产生的。让我们快速看一下动态构建字符串的例子:

public static String toString(T[] array) {

    String result = "[";

    for (int i = 0; i & lt; array.length; i++) {
        result += (array[i] == array ? "this" : array[i]);
        if (i & lt; array.length - 1) {
            result += ", ";
        }
    }

    result += "]";

    return result;
}

这是个看似不错的方法,接收一个字符数组然后返回一个字符串。但是这对于对象内存分配却是灾难性的。

很难看清这语法糖的背后,但是幕后的实际情况是这样的:

public static String toString(T[] array) {

    String result = "[";

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

        StringBuilder sb1 = new StringBuilder(result);
        sb1.append(array[i] == array ? "this" : array[i]);
        result = sb1.toString();

        if (i & lt; 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
类来执行这些拼接操作。这就会有问题了,因为每一次迭代,既隐式地分配了一个临时字符串,又隐式分配了一个临时的
StringBuilder 对象来帮助构建最终的结果。

最佳的方式是避免上面的情况,使用 StringBuilder
和直接的追加,以取代本地拼接操作符(“+”)。下面是一个例子:

public static String toString(T[] array) {

    StringBuilder sb = new StringBuilder("[");

    for (int i = 0; i & lt; array.length; i++) {
        sb.append(array[i] == array ? "this" : array[i]);
        if (i & lt; array.length - 1) {
            sb.append(", ");
        }
    }

    sb.append("]");
    return sb.toString();
}

这里,我们只在方法开始的时候分配了唯一的一个
StringBuilder。至此,所有的字符串和 list
中的元素都被追加到单独的一个StringBuilder中。最终使用 toString()
方法一次性将其转成成字符串返回。

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

建议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) {
        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方法转换成字符串,然后返回结果。

Tip #5: 使用特定的原生类型的集合

Java
标准的集合库简单且支持泛型,允许在使用集合时对类型进行半静态地绑定。比如想要创建一个只存放字符串的
Set 或者存储 Map<Pair, List>这样的 map,这种处理方式是非常棒的。

真正的问题源于当我们想要使用一个 list 存储 int 类型,或者一个 map 存储
double 类型作为
value。因为泛型不支持原生数据类型,因此另外的一种选择是使用包装类型来进行替换,这里我们使用
List 。

这种处理方式是非常浪费的,因为一个 Integer
是一个完全的对象,一个对象的头部占用12个字节以及其内部的所维护的 int
属性,每个Integer 对象总共占用16个字节。这比起存储相同个数的 int 类型的
list 而言,其消耗的空间是它的四倍!比这个更加严重的问题在于,事实上因为
Integer
是真正的对象实例,因此它需要垃圾收集阶段被垃圾收集器所考虑是否要回收。

为了处理这个问题,我们在 Takipi 中使用非常棒的 Trove 集合库。Trove
摒弃了部分泛型的特定来支持特定的使用内存更高效的原生类型的集合。比如,我们使用非常消耗性能的
Map<Integer, Double>,在 Trove 中有另一种特别的选择方案,其形式为
TIntDoubleMap

TIntDoubleMap map = new TIntDoubleHashMap();
map.put(5, 7.0);
map.put(-1, 9.999);
...

Trove
的底层实现使用了原生类型的数组,所以当操作集合的时候不会发生元素的装箱(int->Integer)或者拆箱(Integer->int),
没有存储对象,因为底层使用原生数据类型存储。

让我们看一下下面这个简单的例子:

建议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来替代更好:

TIntDoubleMap map = new TIntDoubleHashMap();  
map.put(5, 7.0);  
map.put(-1, 9.999);  
...

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

最后

随着垃圾收集器持续的改进,以及运行时的优化和 JIT
编译器也变得越来越智能。我们作为开发者将会发现越来越少地考虑如何编写 GC
友好的代码。然而,就目前阶段,不论 G1
如何改进,我们仍然有很多可以做的事来帮 JVM 提升性能。

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

结语

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

以上方法分配了一个新的数组,再将另一个列表的项目填充其中,但只能按倒序填充。

但是,难就难在如何优化增加项目到新列表这一步骤。每次添加后,该列表还需确保其底层数组有足够的空槽能装下新项目。如果能装下,它就会直接在下一个空槽中存储新项目;但如果空间不够,它就会重新分配一个底层数组,将旧数组的内容复制到新数组中,然后再添加新项目。这一过程会导致分配的多个数组都会占据内存,直到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; } return result;}

这样一来,可以保证ArrayList构造函数在最初配置时就能容纳下list.size()个项目,这意味着它不需要再在迭代中重新分配内存。

Guava的集合类则更加先进,允许我们用一个确切数量或估计值来初始化集合。

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

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

当处理数据流时,如从文件中读取数据或从网上下载数据,例如,我们通常可以从数据流中有所发现:

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

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

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

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

更好的处理方式是使用合适的InputStream(本例中是FileInputStream),并直接将其送到分析器,而不是提前将整个文件读到字节数组中。所有主要库会将API直接暴露给解析流,例如:

FileInputStream fis = new FileInputStream;MyProtoBufMessage msg = MyProtoBufMessage.parseFrom;

建议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停顿和更好的整体吞吐量。

字符串可能是任何基于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; sb1.append(array[i] == array ? "this" : array[i]); result = sb1.toString(); if (i < array.length - 1) { StringBuilder sb2 = new StringBuilder; sb2.append; result = sb2.toString(); } } StringBuilder sb3 = new StringBuilder; sb3.append; result = sb3.toString(); return result;}

字符串是不可变的,所以在其连接时并没有被修改,而是依次分配新的字符串。此外,编译器利用标准StringBuilder类来执行的这些链接。这就导致了双重麻烦,在每次循环迭代时,我们得到隐式分配临时字符串,隐式分配临时的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方法转换成字符串,然后返回结果。

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<Integer,
Double>,而用专门的原始集合TintDoubleMap来替代更好:

TIntDoubleMap map = new TIntDoubleHashMap();map.put;map.put(-1, 9.999);...

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

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

(编译自:

OneAPM 为您提供端到端的 Java 应用性能解决方案,我们支持所有常见的 Java
框架及应用服务器,助您快速发现系统瓶颈,定位异常根本原因。分钟级部署,即刻体验,Java
监控从来没有如此简单。想阅读更多技术文章,请访问 OneAPM 官方技术博客。

本文转自 OneAPM 官方博客

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

澳门新葡亰平台官网 1

You can leave a response, or trackback from your own site.

Leave a Reply

网站地图xml地图