JDK 24 新特性概览
JEP 404: Generational Shenandoah (Experimental)
Enhance the Shenandoah garbage collector with experimental generational collection capabilities to improve sustainable throughput, load-spike resilience, and memory utilization.
JEP 404: 代际Shenandoah（实验性）
增强Shenandoah垃圾收集器的实验性代际收集能力，以提高可持续吞吐量、负载峰值弹性和内存利用率。
JEP 450: Compact Object Headers (Experimental)
Reduce the size of object headers in the HotSpot JVM from between 96 and 128 bits down to 64 bits on 64-bit architectures. This will reduce heap size, improve deployment density, and increase data locality.
JEP 450: 紧凑对象头（实验性）
在64位架构的HotSpot JVM中，将对象头的大小从96到128位减少到64位。这将减少堆的大小，提高部署密度，并增加数据局部性。
JEP 472: Prepare to Restrict the Use of JNI
Issue warnings about uses of the Java Native Interface (JNI) and adjust the Foreign Function & Memory (FFM) API to issue warnings in a consistent manner. All such warnings aim to prepare developers for a future release that ensures integrity by default by uniformly restricting JNI and the FFM API. Application developers can avoid both current warnings and future restrictions by selectively enabling these interfaces where essential.
JEP 472: 准备限制JNI的使用
对Java本地接口（JNI）的使用发出警告，并调整外部函数和内存（FFM）API以一致的方式发出警告。所有这些警告旨在为未来的版本做好准备，该版本通过统一限制JNI和FFM API来确保默认完整性。应用程序开发人员可以通过在必要时选择性地启用这些接口来避免当前的警告和未来的限制。
JEP 475: Late Barrier Expansion for G1
Simplify the implementation of the G1 garbage collector's barriers, which record information about application memory accesses, by shifting their expansion from early in the C2 JIT's compilation pipeline to later.
JEP 475: G1的延迟屏障扩展
通过将G1垃圾收集器的屏障扩展从C2 JIT编译管道的早期阶段转移到后期，简化G1垃圾收集器屏障的实现，这些屏障记录有关应用程序内存访问的信息。
JEP 478: Key Derivation Function API (Preview)
Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. This is a preview API.
JEP 478: 密钥派生函数API（预览）
引入一个密钥派生函数（KDF）的API，这是一种用于从秘密密钥和其他数据派生额外密钥的加密算法。这是一个预览API。
JEP 479: Remove the Windows 32-bit x86 Port
Remove the source code and build support for the Windows 32-bit x86 port. This port was deprecated for removal in JDK 21 with the express intent to remove it in a future release.
JEP 479: 移除Windows 32位x86端口
移除Windows 32位x86端口的源代码和构建支持。该端口在JDK 21中被弃用以便移除，明确意图在未来的版本中将其移除。
JEP 483: Ahead-of-Time Class Loading & Linking
Improve startup time by making the classes of an application instantly available, in a loaded and linked state, when the HotSpot Java Virtual Machine starts. Achieve this by monitoring the application during one run and storing the loaded and linked forms of all classes in a cache for use in subsequent runs. Lay a foundation for future improvements to both startup and warmup time.
JEP 483: 提前加载和链接类
通过在HotSpot Java虚拟机启动时使应用程序的类立即可用（以已加载和已链接的状态），来提高启动时间。通过在一次运行期间监控应用程序并将所有类的已加载和已链接形式存储在缓存中，以便在后续运行中使用。为未来对启动和预热时间的改进奠定基础。
JEP 484: Class-File API
Provide a standard API for parsing, generating, and transforming Java class files.
JEP 484: 类文件 API
提供一个标准 API 用于解析、生成和转换 Java 类文件。
JEP 485: Stream Gatherers
Enhance the Stream API to support custom intermediate operations. This will allow stream pipelines to transform data in ways that are not easily achievable with the existing built-in intermediate operations.
JEP 485: 流收集器
增强 Stream API 以支持自定义中间操作。这将允许流管道以现有内置中间操作不易实现的方式转换数据。
JEP 486: Permanently Disable the Security Manager
The Security Manager has not been the primary means of securing client-side Java code for many years, it has rarely been used to secure server-side code, and it is costly to maintain. We therefore deprecated it for removal in Java 17 via JEP 411 (2021). As the next step toward removing the Security Manager, we will revise the Java Platform specification so that developers cannot enable it and other Platform classes do not refer to it. This change will have no impact on the vast majority of applications, libraries, and tools. We will remove the Security Manager API in a future release.
JEP 486: 永久禁用安全管理器
安全管理器多年来一直不是保护客户端Java代码的主要手段，它很少用于保护服务器端代码，并且维护成本高。因此，我们在Java 17中通过 JEP 411（2021）将其弃用以准备移除。作为移除安全管理器的下一步，我们将修订Java平台规范，以便开发人员无法启用它，其他平台类也不再引用它。此更改对绝大多数应用程序、库和工具没有影响。我们将在未来的版本中移除安全管理器API。
JEP 487: Scoped Values (Fourth Preview)
Introduce scoped values, which enable a method to share immutable data both with its callees within a thread, and with child threads. Scoped values are easier to reason about than thread-local variables. They also have lower space and time costs, especially when used together with virtual threads (JEP 444) and structured concurrency (JEP 480). This is a preview API.
JEP 488: Primitive Types in Patterns, instanceof, and switch (Second Preview)
Enhance pattern matching by allowing primitive types in all pattern contexts, and extend instanceof and switch to work with all primitive types. This is a preview language feature.
JEP 488: 模式中的原始类型、instanceof 和 switch（第二次预览）
通过允许在所有模式上下文中使用原始类型来增强模式匹配，并扩展 instanceof 和 switch 以支持所有原始类型。这是一个 预览语言特性。
JEP 489: Vector API (Ninth Incubator)
Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations.
JEP 489: 向量API（第九次孵化）
引入一个API，用于表达向量计算，能够在运行时可靠地编译为支持的CPU架构上的最佳向量指令，从而实现比等效标量计算更优的性能。
JEP 490: ZGC: Remove the Non-Generational Mode
Remove the non-generational mode of the Z Garbage Collector (ZGC).
JEP 490: ZGC: 移除非代际模式
移除Z垃圾收集器（ZGC）的非代际模式。
JEP 491: Synchronize Virtual Threads without Pinning
Improve the scalability of Java code that uses synchronized methods and statements by arranging for virtual threads that block in such constructs to release their underlying platform threads for use by other virtual threads. This will eliminate nearly all cases of virtual threads being pinned to platform threads, which severely restricts the number of virtual threads available to handle an application's workload.
JEP 492: Flexible Constructor Bodies (Third Preview)
In constructors in the Java programming language, allow statements to appear before an explicit constructor invocation, i.e., super(..) or this(..). The statements cannot reference the instance under construction, but they can initialize its fields. Initializing fields before invoking another constructor makes a class more reliable when methods are overridden. This is a preview language feature.
JEP 492: 灵活的构造函数主体（第三次预览）
在Java编程语言的构造函数中，允许在显式构造函数调用之前出现语句，即super(..)或this(..)。这些语句不能引用正在构建的实例，但可以初始化其字段。在调用另一个构造函数之前初始化字段，使得类在方法被重写时更加可靠。这是一个预览语言特性。
JEP 493: Linking Run-Time Images without JMODs
Reduce the size of the JDK by approximately 25% by enabling the jlink tool to create custom run-time images without using the JDK's JMOD files. This feature must be enabled when the JDK is built; it will not be enabled by default, and some JDK vendors may choose not to enable it.
JEP 493: 无需JMOD链接运行时镜像
通过启用 jlink 工具创建自定义运行时镜像，而无需使用JDK的JMOD文件，从而将JDK的大小减少约25%。此功能必须在构建JDK时启用；默认情况下不会启用，并且某些JDK供应商可能选择不启用此功能。
JEP 494: Module Import Declarations (Second Preview)
Enhance the Java programming language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries, but does not require the importing code to be in a module itself. This is a preview language feature.
JEP 494: 模块导入声明（第二次预览）
增强Java编程语言，使其能够简洁地导入模块所导出的所有包。这简化了模块库的重用，但不要求导入代码本身也在一个模块中。这是一个预览语言特性。
JEP 495: Simple Source Files and Instance Main Methods (Fourth Preview)
Evolve the Java programming language so that beginners can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of the language, beginners can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. Experienced developers can likewise enjoy writing small programs succinctly, without the need for constructs intended for programming in the large. This is a preview language feature.
JEP 495: 简单源文件和实例主方法（第四次预览）
发展Java编程语言，使初学者能够在不需要理解为大型程序设计的语言特性时，编写他们的第一个程序。初学者可以编写单类程序的简化声明，并随着技能的提高，顺畅地扩展他们的程序以使用更高级的特性，而不是使用语言的单独方言。经验丰富的开发者同样可以享受简洁地编写小程序，而无需使用为大型编程而设计的构造。这是一个预览语言特性。
JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
Enhance the security of Java applications by providing an implementation of the quantum-resistant Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). Key encapsulation mechanisms (KEMs) are used to secure symmetric keys over insecure communication channels using public key cryptography. ML-KEM is designed to be secure against future quantum computing attacks. It has been standardized by the United States National Institute of Standards and Technology (NIST) in FIPS 203.
JEP 496: 量子抗性模块-基于格的密钥封装机制
通过提供量子抗性模块-基于格的密钥封装机制（ML-KEM）的实现，增强Java应用程序的安全性。密钥封装机制（KEM）用于通过公钥密码学在不安全的通信通道上保护对称密钥。ML-KEM旨在抵御未来量子计算攻击。它已被美国国家标准与技术研究院（NIST）在FIPS 203中标准化。
JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm
Enhance the security of Java applications by providing an implementation of the quantum-resistant Module-Lattice-Based Digital Signature Algorithm (ML-DSA). Digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of signatories. ML-DSA is designed to be secure against future quantum computing attacks. It has been standardized by the United States National Institute of Standards and Technology (NIST) in FIPS 204.
JEP 497: 抗量子模块-基于格的数字签名算法
通过提供抗量子模块-基于格的数字签名算法（ML-DSA）的实现，增强Java应用程序的安全性。数字签名用于检测数据的未经授权的修改，并验证签署者的身份。ML-DSA旨在抵御未来的量子计算攻击。它已被美国国家标准与技术研究院（NIST）在FIPS 204中标准化。
JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe
Issue a warning at run time on the first occasion that any memory-access method in sun.misc.Unsafe is invoked. All of these unsupported methods were terminally deprecated in JDK 23. They have been superseded by standard APIs, namely the VarHandle API (JEP 193, JDK 9) and the Foreign Function & Memory API (JEP 454, JDK 22). We strongly encourage library developers to migrate from sun.misc.Unsafe to supported replacements, so that applications can migrate smoothly to modern JDK releases.
JEP 499: Structured Concurrency (Fourth Preview)
Simplify concurrent programming by introducing an API for structured concurrency. Structured concurrency treats groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is a preview API.
JEP 499: 结构化并发（第四次预览）
通过引入一个用于 结构化并发 的API，简化并发编程。结构化并发将不同线程中运行的相关任务组视为一个单一的工作单元，从而简化错误处理和取消，提高可靠性，并增强可观察性。这是一个预览API。
JEP 501: Deprecate the 32-bit x86 Port for Removal
Deprecate the 32-bit x86 port, with the intent to remove it in a future release. This will thereby deprecate the Linux 32-bit x86 port, which is the only 32-bit x86 port remaining in the JDK. It will also, effectively, deprecate any remaining downstream 32-bit x86 ports. After the 32-bit x86 port is removed, the architecture-agnostic Zero port will be the only way to run Java programs on 32-bit x86 processors.
JEP 501: 弃用32位x86端口以便移除
弃用32位x86端口，计划在未来的版本中移除。这将同时弃用Linux 32位x86端口，这是JDK中唯一剩余的32位x86端口。实际上，这也将弃用任何剩余的下游32位x86端口。在32位x86端口被移除后，架构无关的Zero端口将是唯一在32位x86处理器上运行Java程序的方法。