共计 3968 个字符，预计需要花费 10 分钟才能阅读完成。
起源：https://medium.com/@benweidig
只管 Java 是我应用过的向后兼容水平最高的语言和环境之一，但始终存在性能弃用甚至删除的可能性。Java 21 将弃用两个性能，这就是咱们明天要探讨的内容。
举荐一个开源收费的 Spring Boot 实战我的项目：
https://github.com/javastacks/spring-boot-best-practice
1、为什么要弃用性能？
弃用代码或性能意味着不激励应用它，并且可能在将来的版本中不再存在。为什么不激励它可能有很多起因。
弃用的最常见起因是：
- 它已被更好的代替计划所取代。
- 存在设计缺点，甚至应用起来可能存在危险。但因为向后兼容性，它不能立刻删除，或者基本不能删除。
- 它被认为是多余的，应该删除以简化零碎及其应用形式。
- 将来的更新将使得反对旧性能 / 代码变得不可能 / 不切实际。
无论根本原因如何，已弃用的性能依然是零碎的一部分，因而依然可用，最起码到当初。
弃用 Windows 32 位 x86 端口
JEP 449 旨在弃用 Windows 的 32 位 x86 反对，最终目标是在未来齐全删除它。
这种弃用及其将来删除背地的起因次要是技术性的。
Windows 32 位反对
为任何零碎提供软件总是须要决定您理论想要反对哪些平台。针对不再受反对的平台或版本是可能的，但通常意味着减少反对工作、向后移植、自行修复内容等。
以 Windows 平台为例，最初一个 32 位版本于 2020 年公布，官网反对于 2025 年 10 月完结。
如果您晓得 64 位 Windows 如何解决 32 位应用程序，您可能想晓得为什么不能通过 Windows 集成的 WOW64 模仿层来运行 JVM？嗯，通常能够以这种形式运行应用程序，但性能会急剧下降。
这就是 OpenJDK 团队决定持续弃用的起因，因为它只影响 Java 的将来版本。旧零碎依然能够应用删除之前的所有 Java 版本。
Java 21 中的一项间接更改会影响 JDK 的构建过程，因为默认状况下禁用配置构建的可能性。尝试运行 bash ./configure 会呈现谬误：
...
checking compilation type... native
configure: error: The Windows 32-bit x86 port is deprecated and may be removed in a future release. \
Use --enable-deprecated-ports=yes to suppress this error.
configure exiting with result code 1 因为该性能只是被弃用，而不是被删除，因而 OpenJDK 团队增加了新的配置选项（如谬误所示），--enable-deprecated-ports=yes 以依然容许配置。然而，会收回正告以强调弃用和将来可能的删除。
$ bash ./configure --enable-deprecated-ports=yes
...
checking compilation type... native
configure: WARNING: The Windows 32-bit x86 port is deprecated and may be removed in a future release.
...
Build performance summary:
* Cores to use: 32
* Memory limit: 96601 MB
The following warnings were produced. Repeated here for convenience:
WARNING: The Windows 32-bit x86 port is deprecated and may be removed in a future release.虚构 VS 内核线程
Java 21 充斥了令人敬畏的新性能，虚构线程 (JEP 444) 的增加就是其中之一。它引入了轻量级（虚构）线程，这可能会通过缩小编写、保护和察看此类应用程序所需的工作量，从而显着扭转咱们解决 Java 中高吞吐量并发应用程序的形式。它们的开销比传统平台（内核）线程少得多。
然而，在 Windows 32 位 x86 上，因为技术限度，此性能必须回退到内核线程。底层平台的这种缺失性能通常是将来弃用和删除的无力指标。
尽管如此，您依然能够编写和应用新的线程代码，但在实际操作中却短少预期的益处。
已弃用，但尚未删除
正如您所看到的，弃用是有情理的，因为 Windows 32 位 x86 无论如何都无奈运行。此外，针对特定平台进行构建依然是可能的，只是目前不激励这样做。因而，如果您依然须要反对遗留零碎并晓得您在做什么以及结果是什么，您依然能够应用它。
禁止动静加载代理
代理应用 Instrumentation API 通过更改 JVM 中已加载的字节码来批改现有应用程序。这使您可能更改应用程序的行为，而无需理论更改其源代码。它通常用于分析器和监督工具（例如 Datadog 和 YourKit）、面向方面的编程等等。
如何加载代理
有两种办法能够加载代理，一种是通过增加参数或调用来动态加载，另一种是通过运行如下代码从另一个应用程序动静加载：-javaagent:agent-to-load.jar-agentlib:optionsjava
import java.lang.management.ManagementFactory;
import com.sun.tools.attach.VirtualMachine;
public class DynamicAgentLoader {public static void main(String... args) {
int pidOfOtherJVM = ...;
File agentJar = ...;
try {VirtualMachine vm = VirtualMachine.attach(pidOfOtherJVM);
vm.loadAgent(agentJar.toAbsolutePath);
// ... do your work
vm.detach();} catch (Exception e) {// ...}
}
}第一个选项问题不大。这是对 JVM 代理的明确且无意的应用。然而，后者是间接的，并且可能不受所连贯的 JVM 的管制。
动静加载的问题
Java 平台默认致力于实现完整性，为咱们构建应用程序提供弱小而松软的根底。代理的设计思考到了最好的用意，为您提供（良性）工具的力量。然而，为了确保这种完整性，通过（动静）代理进行检测是一个大问题，因为它们超出了您的间接管制范畴，并且可能会对您的应用程序造成严重破坏。这就是为什么您作为应用程序的所有者必须对容许和加载哪些代理做出无意识且明确的决定。
在 Java 21 中，您依然能够加载动静代理，但 JVM 会生成多个正告，告诉您潜在的问题以及如何暗藏这些正告：
WARNING: A {Java,JVM TI} agent has been loaded dynamically (file:/path/to/agent.jar)
WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning
WARNING: If a serviceability tool is not in use, please run with -Djdk.instrument.traceUsage for more information
WARNING: Dynamic loading of agents will be disallowed by default in a future release将来的 Java 版本将默认禁止加载动静代理，并且任何应用 Attach API 都会引发异样：
com.sun.tools.attach.AgentLoadException: Failed to load agent library: \
Dynamic agent loading is not enabled. Use -XX:+EnableDynamicAgentLoading \
to launch target VM. 异样音讯包含启用动静代理加载所需的步骤：参数 -XX:+EnableDynamicAgentLoading。因而，如果您无意识地决定容许动静代理，那么您依然能够。
立刻禁用动静加载
到目前为止，仅收回正告。然而，您能够齐全禁止动静加载 Java 代理。您能够通过应用将（加号）与（破折号 / 减号）-XX:-EnableDynamicAgentLoading 替换的参数来执行此操作，以强化您的应用程序或为行将到来的更改做好筹备。+-
2、论断
本文中提到的两个性能的弃用对我来说是有情理的。
Windows 10 32 位 x86 反对是一项技术债权，妨碍了翻新，例如利用虚构线程的全副性能。
动静加载代理重大侵害了 Java 平台的完整性，并且存在潜在的平安危险。如果攻击者“足够靠近”能够连贯到另一个 JVM，那么您可能会遇到更大的问题。
尽管如此，咱们始终必须意识到未来可能会发生变化或删除的内容，因为咱们很可能无奈决定它何时产生。Java 通常对弃用和删除工夫框架相当慷慨，某些性能可能会弃用数十年，但看不到删除的迹象。所以很天然地，咱们是否应该应用已弃用的 API 的问题就呈现了。
在我看来，如果可能的话，咱们应该尽量避免应用已弃用的 API。随着工夫的推移，它正在成为技术债权，最终必须偿还。没有什么比因为不相干的起因而须要降级代码更有压力的了，而且您多年来依赖的一些已弃用的性能最终被删除，使得降级形式比须要的更加简单。
更多文章举荐：
1.Spring Boot 3.x 教程，太全了！
2.2,000+ 道 Java 面试题及答案整顿 (2024 最新版)
3. 收费获取 IDEA 激活码的 7 种形式（2024 最新版）
感觉不错，别忘了顺手点赞 + 转发哦！