lambda表达式中变量的注意事项

lambda表达式中变量的注意事项

前言

The restriction to effectively final variables prohibits access to dynamically-changing local variables, whose capture would likely introduce concurrency problems.

在Java的线程模型中,栈帧中的局部变量是线程私有的,永远不需要进行同步。假如说允许通过匿名内部类把栈帧中的变量地址泄漏出去(逃逸),就会引发非常可怕的后果:一份“本来被Java线程模型规定永远是线程私有的数据”可能被并发访问!哪怕它不被并发访问,栈中变量的内存地址泄漏到栈帧之外这件事本身已经足够危险了,这是Java这种内存安全的语言绝对无法容忍的

这才是本质原因。

举例描述

  • 下面是比较长的答案。对于如下代码:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    例子1:
    public void doSomething() {

    int value = 0;

    IntStream.range(0, 10).forEach(i -> value++ );

    }

    你会得到一个编译错误:Variable used in lambda expression should be final or effectively final。如果从头分析一下跟这个问题相关的知识,事情要从Java 8之前就存在的匿名内部类说起:


    例子2:
    public void doSomething() {

    int value = 0;

    Executors.newSingleThreadExecutor().submit(new Runnable() {


    @Override
    public void run() {undefined
    value++;
    }
    });
    }

    同样,你会得到一个编译错误:Variable is accessed within inner class. Needs to be declared final.
  1. 第一个问题,为什么存在这样的限制?
    要回答这个问题,我们需要首先明白,匿名内部类外面的value和里面的value是同一个内存地址中的数据么?
  • 很明显不是,因为我们都知道,局部变量存在于栈帧的局部变量表中,一旦方法结束,栈帧被销毁,这个变量(这份数据)就不再存在
  • 但是匿名内部类中的value可能在栈帧销毁后继续存在(比如在这个例子中,匿名内部类被提交到了线程池中)。
  • 所以,只有一个可能,在匿名内部类被创建的时候,被捕获的局部变量发生了复制。
    • 如果我们允许在匿名内部类中执行value++操作,带来的后果就是,匿名内部类中的value的拷贝被更新了,但是原先的value不会受到任何影响(因为它可能已经不存在了)——你看上去好像两个value是同一个地址,同一份数据,但是实际上发生了拷贝,和方法调用的值传递如出一辙。这是很可怕的一件事情,它会让你误以为,在匿名内部类中执行value++会改变原先的局部变量value
  1. 这还不是最可怕的。最可怕的是,如果允许匿名内部类修改外面的局部变量,会颠覆掉整个Java线程模型!!!!!!

The restriction to effectively final variables prohibits access to dynamically-changing local variables, whose capture would likely introduce concurrency problems.

  • 在Java的线程模型中,栈帧中的局部变量是线程私有的,永远不需要进行同步。但是,假如说我们通过匿名内部类把栈帧中的变量地址泄漏出去,就会引发非常可怕的后果:一份“本来被Java线程模型规定永远是线程私有的数据”可能被并发访问!!!

3. 解决方法

  1. 因此,在Java 8之前,编译器会强迫你加上一个final关键字:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public void doSomething() {

final int value = 0; // 不声明final不给过编译,你给老子死了这条修改的心吧

Executors.newSingleThreadExecutor().submit(new Runnable() {

@Override

public void run() {

System.out.println(value);

}

});
}
  1. 第二个问题:那为什么Java 8之后我可以不写final了呢?
  • Java 8引入了lambda表达式,我们从此可以非常方便地编写大量的小代码块,但是在捕获外围的局部变量这件事上,lambda表达式和匿名内部类没有任何区别——被捕获的局部变量必须是final的。这就带来了一个问题,继续坚持把局部变量声明成final的话,烦也烦死了。 因此,JLS做出了一个妥协:

  • 假如一个局部变量在整个生命周期中都没有被改变(指向),那么它就是effectively final的——换句话说,不是final,胜似final。这样的局部变量也允许被lambda表达式或者匿名内部类所捕获,不过只能看不能摸——可以读取,但是不能修改。

  1. 下一个问题是,老子就是想在lambda表达式里面改外面的值!你咬我啊!
  • 为什么转换成一个AtomicInteger就可以了呢?这跟线程安全没有半毛钱关系,纯粹是利用了这样一个技巧:AtomicInteger可以当作int的容器。因为它是在堆上被分配的,我们完全没有改变这个局部变量的指向(effectively final成立),就达到了修改其中数据的目的。
打赏
  • 版权声明: 本博客所有文章除特别声明外,均采用 Apache License 2.0 许可协议。转载请注明出处!
  • © 2019-2022 Zhuuu
  • PV: UV:

请我喝杯咖啡吧~

支付宝
微信