Java 9中如何对IntegerCache进行修改详解

在开始本文的正文之前，我们下面来看看下面这段代码：

java中integer类的integercache的作用

包名：java.lang

文件名：integer.java

方法名：integercache

方法的代码如下：

private static class integercache { 
static final int high; 
static final integer cache[]; 

static { 
final int low = -128; 

// high value may be configured by property 
int h = 127; 
if (integercachehighpropvalue != null) { 
// use long.decode here to avoid invoking methods that 
// require integer's autoboxing cache to be initialized 
int i = long.decode(integercachehighpropvalue).intvalue(); 
i = math.max(i, 127); 
// maximum array size is integer.max_value 
h = math.min(i, integer.max_value - -low); 
} 
high = h; 

cache = new integer[(high - low) + 1]; 
int j = low; 
for(int k = 0; k < cache.length; k++) 
cache[k] = new integer(j++); 
} 

private integercache() {} 
} 

我们在代码中看到，low为-128，high为127，这样的话，在java编程中，如果要使用-128——127这个区间的对象的话，是直接使用这个cache中的对象的。

上面是段简单的介绍，帮助大家理解下integercache，下面开始本文的正文：

引言

5 年前，我在 hungarian 上发表了一篇关于 jdk 中如何改变 integercache 的文章。这种做法其实是深入进 java 运行时，在实际并没有使用的场景。当你开发这些研究代码时，你才能更好的理解反射是如何工作的，以及 integer 类是如何实现的。

integer 类有一个私有的嵌套内，名为 integercache ，包含了值从 -127 到 128 的 integer 对象。

当代码需要从 int 类型封箱成 integer 对象，而且值在这个范围内时，那么 java 运行时会使用这个缓存，而不是创建一个新的 integer 对象。这主要是处于性能优化的考虑，我们必须牢记在心的是很多 int 值在程序中很多时候都处于这个范围内（例如数组的下标索引）。

这样做的副作用是，很多时候，使用等号操作符来比较两个 integer 对象时，只要值在范围内都是有效的。这在单元测试中很典型。而在运行模式下，当数值大于 128 时，代码执行会失败。

使用反射来访问 integercache 类时会导致一些奇怪的副作用，注意这会影响到整个的 jvm。如果一个 servlet 重新定义了小的 integer 缓存值，那么所有运行在同一个 tomcat 下的其他 servlet 也遭遇同样问题。

在 lukas eder 和 sitepoint 上面还有其他一些文章描述此问题。

现在我已经开始在玩弄 java 9 的早期发布版本，在我脑海里我一直要做的就是对新的 java 版本进行各种实验。在开始之前，让我们先看看在 java 8 中的做法。

在 lukas 的文章中，我将他的示例代码贴在此处：

import java.lang.reflect.field;
import java.util.random;

public class entropy {
 public static void main(string[] args)
 throws exception {

 // extract the integercache through reflection
 class << ? > clazz = class.forname(
  "java.lang.integer$integercache");
 field field = clazz.getdeclaredfield("cache");
 field.setaccessible(true);
 integer[] cache = (integer[]) field.get(clazz);

 // rewrite the integer cache
 for (int i = 0; i < cache.length; i++) {
  cache[i] = new integer(
  new random().nextint(cache.length));
 }

 // prove randomness
 for (int i = 0; i < 10; i++) {
  system.out.println((integer) i);
 }
 }
}

此代码通过反射方式访问 integercache，然后使用随机值对缓存进行填充（淘气！）。

我们尝试在 java 9 中执行相同的代码，别指望有什么乐趣。当有人尝试违反它时会发现 java 9 的限制更加严格。

exception in thread "main" java.lang.reflect.inaccessibleobjectexception:
 unable to make field static final java.lang.integer[]
 java.lang.integer$integercache.cache
 accessible: module java.base does not "opens java.lang" to unnamed module @1bc6a36e

程序抛出了异常，这个异常在 java 8 中是不会发生的。相当于说对象是不可范文的，因为 java.base 模块的原因，这是 jdk 的组成部分，在每个 java 程序启动时被自动的导入，不允许打开未命名的模块。这个异常是在当我们尝试设置字段可访问属性时抛出的。

我们在 java 8 可轻松访问的对象，现在在 java 9 中不能访问了，因为新的模块系统对此进行了保护。代码只能访问字段、方法和其他用反射能访问的信息，只有当类在相同的模块中，或者模块打开了包用于反射方式访问。这个可以通过  module-info.java 模块定义文件来实现：

module mymodule {
 exports com.javax0.module.demo;
 opens com.javax0.module.demo;
}

这个模块 java.base 不用不用自行打开用于反射访问，特别是未命名模块更不需要。如果我们创建了一个模块并进行命名，那么错误信息将包含模块的名称。

我们能否在程序里打开模块呢？ java.lang.reflect.module 模块有一个 addopens 的方法可以做到。

可行吗？

对开发者来说坏消息是：不可行。它只能在另外一个模块中打开一个模块中的包，并且包已经在该模块中通过调用这个方法打开过。这种方法只能让模块传递给另外的模块权利，前提是另外的模块已经以某种方式打开过相同的包，而不能打开没有打开过的包（译者注：很难理解，不是吗？）。

但与此同时好消息是：java 9 不像 java 8 那么容易被破解。最少这个漏洞被关闭了。看起来 java 开始往专业级发展，而不仅仅是个玩具（译者注：谁说 java 是个玩具了？）。不久的将来你可以非常严肃的将 rpg 和 cobol 语言的项目迁移到 java 上了。（很抱歉，我开玩笑的）

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。

本文翻译自：