快捷導航

Java 17 更新后的 strictfp 關(guān)鍵字

更新時間：2021年09月28日 10:25:33 作者：Bennyhuo

strictfp 可能是最沒有存在感的關(guān)鍵字了，很多人寫了多年 Java 甚至都不知道它的存在，strictfp，字面意思就是嚴格的浮點型。這玩意兒居然還有個關(guān)鍵字，可見其地位還是很高的。下面文章小編就帶大家詳細介紹其關(guān)鍵字,需要的朋友可以參考一下

說起這事兒，我以前做地圖業(yè)務(wù)的時候經(jīng)常需要用到經(jīng)緯度，為了防止精度丟失，在計算之前都要先把經(jīng)緯度乘以 10^6 轉(zhuǎn)成整型。我當年剛?cè)肼汄v訊地圖的第一天，隔壁的大哥就因為給某常年被教做產(chǎn)品的聊天 APP 接入地圖 SDK 時遇到了 Marker 反復(fù)橫跳的事情，后來分析就是跟精度有關(guān)。

那么，strict fp 跟這個高貴的 4 有關(guān)系嗎？如果有關(guān)系，那這次更新是特意加入了這個高貴的 4 嗎？顯然不應(yīng)該這么搞笑。因為這個高貴的 4 其實是源自于 IEEE 754 對浮點型的定義，編程語言只要是按照標準實現(xiàn)了浮點型，結(jié)果都是一樣的：

所以這個 strict fp 是什么呢？

Java 從 1.2 開始引入了一個關(guān)鍵字：strictfp，字面意思就是嚴格的浮點型。這玩意兒居然還有個關(guān)鍵字，可見其地位還是很高的。

那么問題來了，為什么要引入這么個奇怪的東西呢？我翻了翻文檔發(fā)現(xiàn)（不然還能怎樣，那個時候我才剛開始學五筆。。。），在上世紀 90 年代，Java 虛擬機為了保持原有的浮點型語義，在兼容 x86 架構(gòu)的處理器上執(zhí)行 x87 指令集（是 x86 指令集的一個關(guān)于浮點型的子集）的情況時開銷很大，性能上令人很不滿意，于是加入 strictfp 來表示原有的浮點型語義（即 IEEE 754 規(guī)定的那樣），而默認的浮點型則采用了更加寬松的語義，這樣算是一個折中的方案。必要時使用 strictfp 很多時候就是為了確保 Java 代碼的可移植性，這其實也不難理解。

不過，這個問題很快得到了解決。在 SSE2 (Streaming SIMD Extensions 2) 擴展指令集隨著奔騰 4 發(fā)布以后，Java 虛擬機有了更直接的方式來實現(xiàn)嚴格的浮點型語義，于是這個問題就不再存在了。

顯然，對于我們絕大多數(shù)程序員來講，特別是后來的所有 Android 開發(fā)者來講，這個問題根本不存在，這更新簡直跟沒更一樣。說著我還看了一眼旁邊的 Apple Silicon，你說是不是呢 M1？

當然，如果你對這個更新點感興趣，我建議你翻一下老版本當中的 StrictMath 類。在這里，你還可以看到一些 strictfp 的使用場景 —— 而在 Java 17 當中，StrictMath 已經(jīng)完全淪為 Math 的馬甲了。

Java 16（源碼來自于 Liberica JDK）

// StrictMath.java
public static strictfp double toRadians(double angdeg) {
    // Do not delegate to Math.toRadians(angdeg) because
    // this method has the strictfp modifier.
    return angdeg * DEGREES_TO_RADIANS;
}

Java 17（源碼來自于 Oracle JDK）

// StrictMath.java
public static double toRadians(double angdeg) {
    return Math.toRadians(angdeg);
}

我們也不妨看一下 Android 的實現(xiàn)：

Android 30

public static strictfp double toRadians(double angdeg) {
    // Do not delegate to Math.toRadians(angdeg) because
    // this method has the strictfp modifier.
    return angdeg / 180.0 * PI;
}

Android 的 JDK 代碼來自于 OpenJDK，連注釋都沒改過。