jvm - 原始包装器实例化是否会导致 JDK 1.6 中的内存分配

Question

来自 PMD:

IntegerInstantiation: In JDK 1.5, calling new Integer() causes memory allocation. Integer.valueOf() is more memory friendly.

ByteInstantiation: In JDK 1.5, calling new Byte() causes memory allocation. Byte.valueOf() is more memory friendly.

ShortInstantiation: In JDK 1.5, calling new Short() causes memory allocation. Short.valueOf() is more memory friendly.

LongInstantiation: In JDK 1.5, calling new Long() causes memory allocation. Long.valueOf() is more memory friendly.

这同样适用于 JDK 1.6 吗？我只是想知道编译器或 jvm 是否将其优化为各自的 valueof 方法。

Answer 1

理论上，编译器可以优化一小部分情况，其中(例如)使用new Integer(n)而不是推荐Integer.valueOf(n)。

首先，我们应该注意，只有当编译器能够保证包装对象永远不会使用 == 或 != 与其他对象进行比较时，才能应用优化>。 (如果发生这种情况，则优化会更改包装器对象的语义，使得“==”和“!=”的行为方式与 JLS 相反。)

有鉴于此，这种优化不太可能值得实现:

1. 优化只会帮助那些忽略 javadoc 等建议的编写不佳的应用程序。对于编写良好的应用程序，测试是否可以应用优化只会减慢优化器的速度；例如JIT 编译器。

2. 即使对于编写得不好的应用程序，允许优化的位置的限制也意味着对 new Integer(n) 的实际调用很少有资格进行优化。在大多数情况下，跟踪可能使用 new 表达式创建的包装器的所有位置的成本太高。如果在图中包含反射，则除了局部变量之外，几乎不可能跟踪任何内容。由于原始包装器的大多数使用都需要将它们放入集合中，因此很容易看出几乎不会发现(通过实际优化器)允许进行优化。

3. 即使在实际应用优化的情况下，它也仅对有限范围内的 n 值有帮助。例如，对较大的 n 调用 Integer.valueOf(n) 将始终创建一个新对象。