盡管JAVA 是我使用過(guò)的向后兼容程度最高的語(yǔ)言和環(huán)境之一，但始終存在功能棄用甚至刪除的可能性。Java 21 將棄用兩個(gè)功能，這就是我們今天要討論的內(nèi)容。
1 為什么要棄用功能？
棄用代碼或功能意味著不鼓勵(lì)使用它，并且可能在未來(lái)的版本中不再存在。為什么不鼓勵(lì)它可能有很多原因。
棄用的最常見(jiàn)原因是：
- 它已被更好的替代方案所取代。
- 存在設(shè)計(jì)缺陷，甚至使用起來(lái)可能存在危險(xiǎn)。但由于向后兼容性，它不能立即刪除，或者根本不能刪除。
- 它被認(rèn)為是多余的，應(yīng)該刪除以簡(jiǎn)化系統(tǒng)及其使用方式。
- 未來(lái)的更新將使得支持舊功能/代碼變得不可能/不切實(shí)際。
無(wú)論根本原因如何，已棄用的功能仍然是系統(tǒng)的一部分，因此仍然可用，最起碼到現(xiàn)在。
棄用 windows 32 位 x86 端口
JEP449旨在棄用 Windows 的 32 位 x86 支持，最終目標(biāo)是在將來(lái)完全刪除它。
這種棄用及其未來(lái)刪除背后的原因主要是技術(shù)性的。
Windows 32 位支持
為任何系統(tǒng)提供軟件總是需要決定您實(shí)際想要支持哪些平臺(tái)。針對(duì)不再受支持的平臺(tái)或版本是可能的，但通常意味著增加支持工作、向后移植、自行修復(fù)內(nèi)容等。
以Windows平臺(tái)為例，最后一個(gè)32位版本于2020年發(fā)布，官方支持于2025年10月結(jié)束。
如果您知道 64 位 Windows 如何處理 32 位應(yīng)用程序，您可能想知道為什么不能通過(guò) Windows集成的 WOW64 模擬層來(lái)運(yùn)行 JVM ？嗯，通常可以以這種方式運(yùn)行應(yīng)用程序，但性能會(huì)急劇下降。
這就是OpenJDK 團(tuán)隊(duì)決定繼續(xù)棄用的原因，因?yàn)樗挥绊?Java 的未來(lái)版本。舊系統(tǒng)仍然可以使用刪除之前的所有 Java 版本。
Java 21 中的一項(xiàng)直接更改會(huì)影響 JDK 的構(gòu)建過(guò)程，因?yàn)槟J(rèn)情況下禁用配置構(gòu)建的可能性。嘗試運(yùn)行bash ./configure會(huì)出現(xiàn)錯(cuò)誤：
...
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 團(tuán)隊(duì)添加了新的配置選項(xiàng)（如錯(cuò)誤所示），--enable-deprecated-ports=yes以仍然允許配置。但是，會(huì)發(fā)出警告以強(qiáng)調(diào)棄用和未來(lái)可能的刪除。
$ 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 內(nèi)核線程
Java 21 充滿了令人敬畏的新功能，虛擬線程 (JEP 444)的添加就是其中之一。它引入了輕量級(jí)（虛擬）線程，這可能會(huì)通過(guò)減少編寫、維護(hù)和觀察此類應(yīng)用程序所需的工作量，從而顯著改變我們處理 Java 中高吞吐量并發(fā)應(yīng)用程序的方式。它們的開(kāi)銷比傳統(tǒng)平臺(tái)（內(nèi)核）線程少得多
然而，在 Windows 32 位 x86 上，由于技術(shù)限制，此功能必須回退到內(nèi)核線程。底層平臺(tái)的這種缺失功能通常是未來(lái)?xiàng)売煤蛣h除的有力指標(biāo)。
盡管如此，您仍然可以編寫和使用新的線程代碼，但在實(shí)際操作中卻缺少預(yù)期的好處。
已棄用，但尚未刪除
正如您所看到的，棄用是有道理的，因?yàn)?Windows 32 位 x86 無(wú)論如何都無(wú)法運(yùn)行。此外，針對(duì)特定平臺(tái)進(jìn)行構(gòu)建仍然是可能的，只是目前不鼓勵(lì)這樣做。因此，如果您仍然需要支持遺留系統(tǒng)并知道您在做什么以及后果是什么，您仍然可以使用它。
禁止動(dòng)態(tài)加載代理
代理使用Instrumentation API通過(guò)更改 JVM 中已加載的字節(jié)碼來(lái)修改現(xiàn)有應(yīng)用程序。這使您能夠更改應(yīng)用程序的行為，而無(wú)需實(shí)際更改其源代碼。它通常用于分析器和監(jiān)視工具（例如Datadog和YourKit）、面向方面的編程等等。
如何加載代理
有兩種方法可以加載代理，一種是通過(guò)添加參數(shù)或調(diào)用來(lái)靜態(tài)加載，另一種是通過(guò)運(yùn)行如下代碼從另一個(gè)應(yīng)用程序動(dòng)態(tài)加載：-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) {
// ...
}
}
}第一個(gè)選項(xiàng)問(wèn)題不大。這是對(duì) JVM 代理的明確且有意的使用。然而，后者是間接的，并且可能不受所連接的 JVM 的控制。
動(dòng)態(tài)加載的問(wèn)題
Java 平臺(tái)默認(rèn)致力于實(shí)現(xiàn)完整性，為我們構(gòu)建應(yīng)用程序提供強(qiáng)大而堅(jiān)實(shí)的基礎(chǔ)。代理的設(shè)計(jì)考慮到了最好的意圖，為您提供（良性）工具的力量。然而，為了確保這種完整性，通過(guò)（動(dòng)態(tài)）代理進(jìn)行檢測(cè)是一個(gè)大問(wèn)題，因?yàn)樗鼈兂隽四闹苯涌刂品秶⑶铱赡軙?huì)對(duì)您的應(yīng)用程序造成嚴(yán)重破壞。這就是為什么您作為應(yīng)用程序的所有者必須對(duì)允許和加載哪些代理做出有意識(shí)且明確的決定。
插播一條，如果你近期準(zhǔn)備面試跳槽，建議在ddkk.com在線刷題，涵蓋 1萬(wàn)+ 道 Java 面試題，幾乎覆蓋了所有主流技術(shù)面試題，還有市面上最全的技術(shù)棧500套，精品系列教程，免費(fèi)提供。
在Java 21 中，您仍然可以加載動(dòng)態(tài)代理，但 JVM 會(huì)生成多個(gè)警告，通知您潛在的問(wèn)題以及如何隱藏這些警告：
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未來(lái)的Java 版本將默認(rèn)禁止加載動(dòng)態(tài)代理，并且任何使用Attach API都會(huì)引發(fā)異常：
com.sun.tools.attach.AgentLoadException: Failed to load agent library:
Dynamic agent loading is not enabled. Use -XX:+EnableDynamicAgentLoading
to launch target VM.異常消息包括啟用動(dòng)態(tài)代理加載所需的步驟：參數(shù)-XX:+EnableDynamicAgentLoading。因此，如果您有意識(shí)地決定允許動(dòng)態(tài)代理，那么您仍然可以。
立即禁用動(dòng)態(tài)加載
到目前為止，僅發(fā)出警告。但是，您可以完全禁止動(dòng)態(tài)加載 Java 代理。您可以通過(guò)使用將（加號(hào)）與（破折號(hào)/減號(hào)）-XX:-EnableDynamicAgentLoading交換的參數(shù)來(lái)執(zhí)行此操作，以強(qiáng)化您的應(yīng)用程序或?yàn)榧磳⒌絹?lái)的更改做好準(zhǔn)備。+-
2 結(jié)論
本文中提到的兩個(gè)功能的棄用對(duì)我來(lái)說(shuō)是有道理的。
Windows 10 32 位 x86 支持是一項(xiàng)技術(shù)債務(wù)，阻礙了創(chuàng)新，例如利用虛擬線程的全部功能。
動(dòng)態(tài)加載代理嚴(yán)重?fù)p害了 Java 平臺(tái)的完整性，并且存在潛在的安全風(fēng)險(xiǎn)。如果打擊者“足夠接近”可以連接到另一個(gè) JVM，那么您可能會(huì)遇到更大的問(wèn)題。
盡管如此，我們始終必須意識(shí)到將來(lái)可能會(huì)發(fā)生變化或刪除的內(nèi)容，因?yàn)槲覀兒芸赡軣o(wú)法決定它何時(shí)發(fā)生。Java 通常對(duì)棄用和刪除時(shí)間框架相當(dāng)慷慨，某些功能可能會(huì)棄用數(shù)十年，但看不到刪除的跡象。所以很自然地，我們是否應(yīng)該使用已棄用的 API 的問(wèn)題就出現(xiàn)了。
在我看來(lái)，如果可能的話，我們應(yīng)該盡量避免使用已棄用的 API。隨著時(shí)間的推移，它正在成為技術(shù)債務(wù)，最終必須償還。沒(méi)有什么比因?yàn)椴幌嚓P(guān)的原因而需要升級(jí)代碼更有壓力的了，而且您多年來(lái)依賴的一些已棄用的功能最終被刪除，使得升級(jí)方式比需要的更加復(fù)雜。
