JEP 481(作用域值第 3 个预览版)——之前称为范围局部变量(孵化)——提供了第三次预览。该版本只有一个变化,旨在从之前的一轮孵化和两轮预览之外获得额外的经验和反馈:随 JDK 22 交付的 JEP 464(作用域值第 2 个预览版)、随 JDK 21 交付的 JEP 446(作用域值预览版)以及随 JDK 20 交付的 JEP 429(作用域值孵化)。该特性支持在线程内部和线程之间共享不可变数据。
在 JDK 23 中重新预览的作用域值 API 修改了ScopedValue.callWhere
方法。现在,这个方法的操作参数是一个函数式接口。它允许 Java 编译器推断是否可能抛出检查异常。因此,ScopedValue.getWhere
这个方法就不再需要了,而且已经删除。在频繁共享数据的场景中,这会使代码更简洁,而且性能更好。
作用域值使方法能够与其调用者和子线程共享不可变数据。与线程局部变量相比,这可以简化数据流的管理和推断。而且,它们的空间和时间成本更低,特别是在与虚拟线程(JEP 444)和结构化并发(JEP 480)结合使用时。
不过,Java 1.2 中引入的线程局部变量一直是一个简化同一线程内方法间数据共享的传统方法。尽管已经使用了很长时间,但它还是有一些缺点。一个主要的问题是它们毫无约束的可变性,任何代码都可以随时更改线程局部变量的值,这可能导致潜在的不一致。另一个缺点是它们的寿命不受限制;如果开发人员忘记调用remove
方法,值的保存时长可能会超过所需的时长,而这通常会导致内存泄漏。此外,跨线程继承线程局部变量会显著增加开销,因为每个子线程都必须为先前在父线程中写入的每个线程局部变量分配存储空间,这会对性能产生负面影响。
作用域值解决了这个问题,它确保数据是不可变的,并且只能在定义好的作用域中访问。这增强了安全性和性能。
为了说明作用域值的好处,考虑下这样一个 Web 框架,它的上下文需要在不同的方法之间共享,而又不需要显式地将其作为参数传递。使用线程局部变量,该框架可能是这样的:
使用作用域值,其实现会变得更加简洁、高效:
使用线程局部变量,当框架调用用户代码以及当用户代码回调框架方法时,不需要将FrameworkContext
作为方法的参数进行传递。线程局部变量是作为一个隐藏的方法参数:线程调用Framework.serve
中的CONTEXT.set
。然后,Framework.readKey
中的CONTEXT.get
自动就可以看到CONTEXT
的本地副本。实际上,ThreadLocal
字段充当了一个键,用于查找当前线程的FrameworkContext
值。另一方面,使用作用域值简化了这个过程。它消除了可变状态,并且确保上下文只能在runWhere
方法定义好的范围内访问,从而提供了一种更健壮且性能更好的方法。总之,作用域值 API 显著增强了 Java 中跨方法和线程共享数据的方式,促进了更好的编码实践,并提高了应用程序的性能。它非常符合现代并发模型,特别是当虚拟线程出现之后,它为开发人员处理高并发应用程序提供了一个重要的选项。
原文链接:
https://www.infoq.com/news/2024/07/jep-481-enhanced-scoped-values/
评论