JVM 解剖公园:局部变量可用性
Posted ImportNew
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了JVM 解剖公园:局部变量可用性相关的知识,希望对你有一定的参考价值。
(给ImportNew加星标,提高Java技能)
编译:ImportNew/唐尤华
shipilev.net/jvm/anatomy-quarks/8-local-var-reachability/
“离开当前作用域,存储在局部变量中的引用会被回收”,这种说法正确吗?在 Java 中并非如此,代码块还没有结束变量可能已不可用。
1. 写在前面
“[JVM 解剖公园][1]”是一个持续更新的系列迷你博客,阅读每篇文章一般需要5到10分钟。限于篇幅,仅对某个主题按照问题、测试、基准程序、观察结果深入讲解。因此,这里的数据和讨论可以当轶事看,不做写作风格、句法和语义错误、重复或一致性检查。如果选择采信文中内容,风险自负。
Aleksey Shipilёv,JVM 性能极客
推特 [@shipilev][2]
问题、评论、建议发送到 [aleksey@shipilev.net][3]
[1]:https://shipilev.net/jvm-anatomy-park
[2]:http://twitter.com/shipilev
[3]:aleksey@shipilev.net
2. 问题
“离开当前作用域,存储在局部变量中的引用会被回收”,这种说法正确吗?
3. 理论
这种概念植根于许多具有 C/C++ 经验的程序员大脑中。在语言规范中是这样定义的:
>>>
声明为 `auto`、`register`、非 `static` 或 `extern` 局部变量具有自动存续期,对象会持续存在直到退出创建的代码块。
注意:这些对象会按照6.7中的描述初始化并销毁。
如果 `auto` 对象的初始化或析构函数具有副作用,除非符合12.8中的情形,否则不应在代码块结束时销毁对象或其拷贝,也不能作为未使用的对象将其优化。
— C++98 标准
3.7.2 "Automatic storage duration 自动存续期"
>>>
这是一个非常有用的语言特性,它把对象生存周期与语法中的代码块绑定,例如像下面这样:
```java
void method() {
...执行一些操作...
{
MutexLocker ml(mutex);
...在锁机制的保护下执行...
} // ~MutexLocker 解锁
...执行其他操作...
}
```
有 C++ 经验的程序员会自觉地把这种特性应用到 Java 上。尽管没有析构函数,但还是有办法检测不可到达的代码,并采取相应的行动,例如软引用、弱引用、虚引用、finalizer 等。然而,Java 语法中的代码块和 C++ 的工作机制并不相同。例如:
>>>
“Java 编译器优化转换后,可访问的对象数量比通常认为的要少。例如,编译器或生成器会把不再使用的对象置为 `null`,从而加速内存回收”。
— Java8 语言规范
12.6.1 "Implementing Finalization"
>>>
这真的很重要吗?
4. 实验
这种差异很容易通过实验证明,以下面的 `LocalFinalize` 类为例:
```java
public class LocalFinalize {
...
private static volatile boolean flag;
public static void pass() {
MyHook h1 = new MyHook();
MyHook h2 = new MyHook();
while (flag) {
// 循环
}
h1.log();
}
public static class MyHook {
public MyHook() {
System.out.println("Created " + this);
}
public void log() {
System.out.println("Alive " + this);
}
@Override
protected void finalize() throws Throwable {
System.out.println("Finalized " + this);
}
}
}
```
通常认为 `h2` 的生命周期会持续到 `pass` 函数结束。由于函数中有一个循环等待,在 `flag` 设置为 `true` 之前,对象的生命周期不会终止。
从编译结果中可以发现一些有趣的结果。我们设计了下面这个例子:第一次调用 `pass`,进入函数后循环等待一段时间,然后退出。第二次进入函数,会一直循环。
像下面这样:
```java
public static void arm() {
new Thread(() -> {
try {
Thread.sleep(5000);
flag = false;
} catch (Throwable t) {}
}).start();
}
public static void main(String... args) throws InterruptedException {
System.out.println("Pass 1");
arm();
flag = true;
pass();
System.out.println("Wait for pass 1 finalization");
Thread.sleep(10000);
System.out.println("Pass 2");
flag = true;
pass();
}
```
还有一个后台线程,反复执行垃圾回收,触发 `finalize()`。设置完毕([完整源代码][4]),运行代码:
[4]:https://shipilev.net/jvm/anatomy-quarks/8-local-var-reachability/LocalFinalize.java
```shell
$ java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
$ java LocalFinalize
Pass 1
Created LocalFinalize$MyHook@816f27d # 新建 h1
Created LocalFinalize$MyHook@87aac27 # 新建 h2
Alive LocalFinalize$MyHook@816f27d # 调用 h1.log
Wait for pass 1 finalization
Finalized LocalFinalize$MyHook@87aac27 # h1 触发 finalize
Finalized LocalFinalize$MyHook@816f27d # h2 触发 finalize
Pass 2
Created LocalFinalize$MyHook@3e3abc88 # 新建 h1
Created LocalFinalize$MyHook@6ce253f1 # 新建 h2
Finalized LocalFinalize$MyHook@6ce253f1 # h2 触发 finalize (!)
```
意外出现了。因为优化编译器知道最后一次使用 `h2` 发生在分配之后,所以出现第二次调用时 `h2` 触发 finalize 的情况。编译器与垃圾收集器确认对象是否可用时,把 `h2` 认为是不可用对象。因此,`MyHook` 实例被回收,触发 finalize。由于 `h1` 在循环之后被再次使用,因此视为可用,不会触发 finalize。
这是一种很好的特性,使得 GC 无需退出函数执行就能回收本地分配的大量缓存,例如:
```java
void processAndWait() {
byte[] buf = new byte[1024 * 1024];
writeToBuf(buf);
processBuf(buf); // 最后使用!
waitForTheDeathOfUniverse(); // oops
}
```
5. 深入讨论
实际上,可以在各种反汇编结果中查看技术细节。首先,反汇编结果不包含局部变量,`h2` 变量存储的 slot 1 一直保留到方法结尾:
```shell
$ javap -c -v -p LocalFinalize.class
public static void pass();
descriptor: ()V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=2, args_size=0
0: new #17 // class LocalFinalize$MyHook
3: dup
4: invokespecial #18 // Method LocalFinalize$MyHook."<init>":()V
7: astore_0
8: new #17 // class LocalFinalize$MyHook
11: dup
12: invokespecial #18 // Method LocalFinalize$MyHook."<init>":()V
15: astore_1
16: getstatic #10 // Field flag:Z
19: ifeq 25
22: goto 16
25: aload_0
26: invokevirtual #19 // Method LocalFinalize$MyHook.log:()V
29: return
```
加上调试参数(`javac -g`)可以编译生成局部变量表(LVT),看起来局部变量的生命周期“似乎”延续到了方法结束:
```shell
public static void pass();
descriptor: ()V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=2, args_size=0
0: new #17 // class LocalFinalize$MyHook
3: dup
4: invokespecial #18 // Method LocalFinalize$MyHook."<init>":()V
7: astore_0
8: new #17 // class LocalFinalize$MyHook
11: dup
12: invokespecial #18 // Method LocalFinalize$MyHook."<init>":()V
15: astore_1
16: getstatic #10 // Field flag:Z
19: ifeq 25
22: goto 16
25: aload_0
26: invokevirtual #19 // Method LocalFinalize$MyHook.log:()V
29: return
LocalVariableTable:
Start Length Slot Name Signature
8 22 0 h1 LLocalFinalize$MyHook; // 8 + 22 = 30
16 14 1 h2 LLocalFinalize$MyHook; // 16 + 14 = 30
```
这个结果让人疑惑,因为通常认为变量的“作用域”是 LVT 定义的。但事实并非如此,编译器会检查局部变量有没有继续使用并进行优化。在当前的测试中,会发生下面的情况(用伪代码描述):
```java
public static void pass() {
MyHook h1 = new MyHook();
MyHook h2 = new MyHook();
while (flag) {
// 循环
// <这里 gc 安全>
// 这里,编译后的代码能够知道哪些引用存储在寄存器中和堆栈上,
// 这时,"h2" 已经超过了最后使用的地方,map 中没有 "h2" 的信息,
// 因此,垃圾回收会把它视为不可用
}
h1.log();
}
```
加上 `-XX:+PrintAssembly` 选项可以看到下面输出:
```asm
data16 data16 xchg %ax,%ax ; ImmutableOopMap{r10=Oop rbp=Oop}
;*goto {reexecute=1 rethrow=0 return_oop=0}
; - LocalFinalize::pass@22 (line 43)
LOOP:
test %eax,0x15ae2bca(%rip) # 0x00007f30868ff000
; *goto {reexecute=0 rethrow=0 return_oop=0}
; - LocalFinalize::pass@22 (line 43)
; {poll}
movzbl 0x70(%r10),%r8d ;*getstatic flag {reexecute=0 rethrow=0 return_oop=0}
; - LocalFinalize::pass@16 (line 43)
test %r8d,%r8d
jne LOOP ;*ifeq {reexecute=0 rethrow=0 return_oop=0}
; - LocalFinalize::pass@19 (line 43)
```
`ImmutableOopMap{r10=Oop rbp=Oop}` 可以基本上认为 `%r10` 和 `%rbp` 保存了“对象指针”。`%r10` 保存 `this`,通过它读取 `flag`;`%rbp` 保存 `h1` 引用。这里没有 `h2` 引用的信息。
6. 替代方案
延长局部变量的声明周期,可以在接下来的代码中调用局部变量。然而,这种方案很难做到不会带来副作用。比如,“仅仅”调用方法并传入局部变量是不够的,因为方法可能会被内联优化或者进行类似优化。自 Java 9 开始,[java.lang.ref.Reference::reachabilityFence][5] 提供了必要的语法支持。
[5]:http://download.java.net/java/jdk9/docs/api/java/lang/ref/Reference.html#reachabilityFence-java.lang.Object-
如果“只是”希望获得 C++ “代码块结束时释放“这样的特性,可以在 Java 代码块结束时调用 `try-finally`。
7. 观察
Java 局部变量的可用性不由代码块决定,而与最后一次使用有关,并且可能会持续到最后一次使用为止。使用像 finalizer、强引用、弱引用、虚引用这样的方法通知对象不可达,会受到“提前检查”优化带来的影响,即代码块还没有结束变量已不可用。
推荐阅读
(点击标题可跳转阅读)
看完本文有收获?请转发分享给更多人
关注「ImportNew」,提升Java技能
好文章,我在看❤️
以上是关于JVM 解剖公园:局部变量可用性的主要内容,如果未能解决你的问题,请参考以下文章