聊聊Unsafe的一些使用技巧
前言
記得初學(xué) Java 那會,剛學(xué)完語法基礎(chǔ),就接觸到了反射這個 Java 提供的特性,盡管在現(xiàn)在看來,這是非?;A(chǔ)的知識點,但那時候無疑是興奮的,瞬間覺得自己脫離了“Java 初學(xué)者”的隊伍。隨著工作經(jīng)驗的積累,我也逐漸學(xué)習(xí)到了很多類似的讓我為之而興奮的知識點,Unsafe 的使用技巧無疑便是其中一個。
sun.misc.Unsafe 是 JDK 原生提供的一個工具類,包含了很多在 Java 語言看來很 cool 的操作,例如內(nèi)存分配與回收、CAS 操作、類實例化、內(nèi)存屏障等。正如其命名一樣,由于其可以直接操作內(nèi)存,執(zhí)行底層系統(tǒng)調(diào)用,其提供的操作也是比較危險的。Unsafe 在擴展 Java 語言表達(dá)能力、便于在更高層(Java層)代碼里實現(xiàn)原本要在更低層(C層)實現(xiàn)的核心庫功能上起到了很大的作用。
從 JDK9 開始,Java 模塊化設(shè)計的限制,使得非標(biāo)準(zhǔn)庫的模塊都無法訪問到 sun.misc.Unsafe。但在 JDK8 中,我們?nèi)匀豢梢灾苯硬僮?Unsafe,再不學(xué)習(xí),后面可能就沒機會了。
使用 Unsafe
Unsafe 被設(shè)計的初衷,并不是希望被一般開發(fā)者調(diào)用,所以我們不能通過 new 或者工廠方法去實例化 Unsafe 對象,通常可以采用反射的方法獲取到 Unsafe 實例:
public?static?final?Unsafe?unsafe?=?getUnsafe();
static?sun.misc.Unsafe?getUnsafe()?{
????try?{
????????Field?field?=?Unsafe.class.getDeclaredField("theUnsafe");
????????field.setAccessible(true);
????????return??(Unsafe)?field.get(null);
????}?catch?(Exception?e)?{
????????throw?new?RuntimeException(e);
????}
}
拿到之后,便可以用這個全局的單例對象去為所欲為了。
功能概覽

圖片來源于網(wǎng)絡(luò),我直接借用過來了。上圖包含了 Unsafe 的眾多功能,還算全面。如果全部介紹,文章篇幅會過長,形式難免會流水賬,我打算結(jié)合我的一些項目經(jīng)驗以及一些比賽經(jīng)驗,從實踐角度聊聊 Unsafe 的一些使用技巧。
內(nèi)存分配&存取
Java 其實也可以像 C++ 那樣直接操作內(nèi)存,借助 Unsafe 就可以。讓我們先來看一個 ByteBuffer 的示例,我們將會開辟一個 16 字節(jié)的內(nèi)存空間,先后寫入并讀取 4 個 int 類型的數(shù)據(jù)。
public?static?void?testByteBuffer()?{
????ByteBuffer?directBuffer?=?ByteBuffer.allocateDirect(16);
????directBuffer.putInt(1);
????directBuffer.putInt(2);
????directBuffer.putInt(3);
????directBuffer.putInt(4);
????directBuffer.flip();
????System.out.println(directBuffer.getInt());
????System.out.println(directBuffer.getInt());
????System.out.println(directBuffer.getInt());
????System.out.println(directBuffer.getInt());
}
熟悉 nio 操作的同學(xué)對上面的示例應(yīng)該不會感到陌生,這是很基礎(chǔ)也是很標(biāo)準(zhǔn)的內(nèi)存使用方式。那換做是 Unsafe 怎么實現(xiàn)同樣的效果的?
public?static?void?testUnsafe0()?{
????Unsafe?unsafe?=?Util.unsafe;
????long?address?=?unsafe.allocateMemory(16);
????unsafe.putInt(address,?1);
????unsafe.putInt(address?+?4,?2);
????unsafe.putInt(address?+?8,?3);
????unsafe.putInt(address?+?12,?4);
????System.out.println(unsafe.getInt(address));
????System.out.println(unsafe.getInt(address?+?4));
????System.out.println(unsafe.getInt(address?+?8));
????System.out.println(unsafe.getInt(address?+?12));
}
兩段代碼輸出結(jié)果一致:
1
2
3
4
下面針對使用到的 Unsafe 的 API,逐個介紹:
public?native?long?allocateMemory(long?var1);
這個 native 方法分配的是堆外內(nèi)存,返回的 long 類型數(shù)值,便是內(nèi)存的首地址,可以作為 Unsafe 其他 API 的入?yún)ⅰD闳绻娺^ DirectByteBuffer 的源碼,會發(fā)現(xiàn)其實它內(nèi)部就是使用 Unsafe 封裝的。說到 DirectByteBuffer,這里額外提一句,ByteBuffer.allocateDirect 分配的堆外內(nèi)存會受到 -XX:MaxDirectMemorySize 的限制,而 Unsafe 分配的堆外內(nèi)存則不會受到限制,當(dāng)然啦,也不會受到 -Xmx 的限制。如果你正在參加什么比賽并且受到了什么啟發(fā),可以把“爺懂了”打在公屏上。
看到另外兩個 API putInt 和 getInt ,你應(yīng)當(dāng)會意識到,肯定會有其他字節(jié)操作的 API,例如 putByte/putShort/putLong ,當(dāng)然 put 和 get 也是成對出現(xiàn)的。這一系列 API 里面也有注意點,建議需要成對的使用,否則可能會因為字節(jié)序問題,導(dǎo)致解析失敗。可以看下面的例子:
public?static?void?testUnsafe1()?{
????ByteBuffer?directBuffer?=?ByteBuffer.allocateDirect(4);
????long?directBufferAddress?=?((DirectBuffer)directBuffer).address();
????System.out.println("Unsafe.putInt(1)");
????Util.unsafe.putInt(directBufferAddress,?1);
????System.out.println("Unsafe.getInt()?==?"?+?Util.unsafe.getInt(directBufferAddress));
????directBuffer.position(0);
????directBuffer.limit(4);
????System.out.println("ByteBuffer.getInt()?==?"?+?directBuffer.getInt());
????directBuffer.position(0);
????directBuffer.limit(4);
????System.out.println("ByteBuffer.getInt()?reverseBytes?==?"?+?Integer.reverseBytes(directBuffer.getInt()));
}
輸出如下:
Unsafe.putInt(1)
Unsafe.getInt()?==?1
ByteBuffer.getInt()?==?16777216
ByteBuffer.getInt()?reverseBytes?==?1
可以發(fā)現(xiàn)當(dāng)我們使用 Unsafe 進行 putInt,再使用 ByteBuffer 進行 getInt,結(jié)果會不符合預(yù)期,需要對結(jié)果進行字節(jié)序變化之后,才恢復(fù)正確。這其實是因為,ByteBuffer 內(nèi)部判斷了當(dāng)前操作系統(tǒng)的字節(jié)序,對于 int 這種多字節(jié)的數(shù)據(jù)類型,我的測試機器使用大端序存儲,而 Unsafe 默認(rèn)以小短序存儲導(dǎo)致。如果你拿捏不準(zhǔn),建議配套使用寫入和讀取 API,以避免字節(jié)序問題。對字節(jié)序不了解的同學(xué)可以參考我的另外一篇文章:《“字節(jié)序”是個什么鬼》。
內(nèi)存復(fù)制
內(nèi)存復(fù)制在實際應(yīng)用場景中還是很常見的需求,例如上一篇文章我剛介紹過的,堆內(nèi)內(nèi)存寫入磁盤時,需要先復(fù)制到堆外內(nèi)存,再例如我們做內(nèi)存聚合時,需要緩沖一部分?jǐn)?shù)據(jù),也會涉及到內(nèi)存復(fù)制。你當(dāng)然也可以通過 ByteBuffer 或者 set/get 去進行操作,但肯定不如 native 方法來的高效。Unsafe 提供了內(nèi)存拷貝的 native 方法,可以實現(xiàn)堆內(nèi)到堆內(nèi)、堆外到堆外、堆外和堆內(nèi)互相拷貝,總之就是哪兒到哪兒都可以拷貝。
public?native?void?copyMemory(Object?src,?long?offset,?Object?dst?,long?dstOffset,?long?size);
對于堆內(nèi)內(nèi)存來說,我們可以直接給 src 傳入對象數(shù)組的首地址,并且指定 offset 為對應(yīng)數(shù)組類型的偏移量,可以通過 arrayBaseOffset 方法獲取堆內(nèi)內(nèi)存存儲對象的偏移量
public?native?int?arrayBaseOffset(Class>?var1);
例如獲取 byte[] 的固定偏移量可以這樣操作:unsafe.arrayBaseOffset(byte[].class)
對于堆外內(nèi)存來說,會更加直觀一點,dst 設(shè)為 null,dstOffset 設(shè)置為 Unsafe 獲取的內(nèi)存地址即可。
堆內(nèi)內(nèi)存復(fù)制到堆外內(nèi)存的示例代碼:
public?static?void?unsafeCopyMemory()??{
????ByteBuffer?heapBuffer?=?ByteBuffer.allocate(4);
????ByteBuffer?directBuffer?=?ByteBuffer.allocateDirect(4);
????heapBuffer.putInt(1234);
????long?address?=?((DirectBuffer)directBuffer).address();
????Util.unsafe.copyMemory(heapBuffer.array(),?16,?null,?address,?4);
????directBuffer.position(0);
????directBuffer.limit(4);
????System.out.println(directBuffer.getInt());
}
在實際應(yīng)用中,大多數(shù) ByteBuffer 相關(guān)的源碼在涉及到內(nèi)存復(fù)制時,都使用了 copyMemory 方法。
非常規(guī)實例化對象
在 JDK9 模塊化之前,如果不希望將一些類開放給其他用戶使用,或者避免被隨意實例化(單例模式),通常有兩個常見做法
案例一:私有化構(gòu)造器
public?class?PrivateConstructorFoo?{
????private?PrivateConstructorFoo()?{
????????System.out.println("constructor?method?is?invoked");
????}
????public?void?hello()?{
????????System.out.println("hello?world");
????}
}
如果希望實例化該對象,第一時間想到的可能是反射創(chuàng)建
public?static?void?reflectConstruction()?{
??PrivateConstructorFoo?privateConstructorFoo?=?PrivateConstructorFoo.class.newInstance();
??privateConstructorFoo.hello();
}
不出所料,我們獲得了一個異常
java.lang.IllegalAccessException:?Class?io.openmessaging.Main?can?not?access?a?member?of?class?moe.cnkirito.PrivateConstructorFoo?with?modifiers?"private"
稍作調(diào)整,調(diào)用構(gòu)造器創(chuàng)建實例
public?static?void?reflectConstruction2()?{
???Constructor?constructor?=?PrivateConstructorFoo.class.getDeclaredConstructor();
???constructor.setAccessible(true);
???PrivateConstructorFoo?privateConstructorFoo?=?constructor.newInstance();
???privateConstructorFoo.hello();
}
it works!輸出如下:
constructor?method?is?invoked
hello?world
當(dāng)然,Unsafe 也提供了 allocateInstance 方法
public?native?Object?allocateInstance(Class>?var1)?throws?InstantiationException;
也可以實現(xiàn)實例化,而且更為直觀
public?static?void?allocateInstance()?throws?InstantiationException?{
????PrivateConstructorFoo?privateConstructorFoo?=?(PrivateConstructorFoo)?Util.unsafe.allocateInstance(PrivateConstructorFoo.class);
????privateConstructorFoo.hello();
}
同樣 works!輸出如下:
hello?world
注意這里有一個細(xì)節(jié),allocateInstance 沒有觸發(fā)構(gòu)造方法。
案例二:package level 實例
package?moe.cnkirito;
class?PackageFoo?{
????public?void?hello()?{
????????System.out.println("hello?world");
????}
}
注意,這里我定義了一個 package 級別可訪問的對象 PackageFoo,只有 moe.cnkirito 包下的類可以訪問。
我們同樣先嘗試使用反射
package?com.bellamm;
public?static?void?reflectConstruction()?{
??Class>?aClass?=?Class.forName("moe.cnkirito.PackageFoo");
??aClass.newInstance();
}
得到了意料之中的報錯:
java.lang.IllegalAccessException:?Class?io.openmessaging.Main?can?not?access?a?member?of?class?moe.cnkirito.PackageFoo?with?modifiers?""
再試試 Unsafe 呢?
package?com.bellamm;
public?static?void?allocateInstance()?throws?Exception{
????Class>?fooClass?=?Class.forName("moe.cnkirito.PackageFoo");
????Object?foo?=?Util.unsafe.allocateInstance(fooClass);
????Method?helloMethod?=?fooClass.getDeclaredMethod("hello");
????helloMethod.setAccessible(true);
????helloMethod.invoke(foo);
}
由于在 com.bellamm 包下,我們甚至無法在編譯期定義 PackageFoo 類,只能通過反射機制在運行時,獲取 moe.cnkirito.PackageFoo 的方法,配合 Unsafe 實例化,最終實現(xiàn)調(diào)用,成功輸出 hello world。
我們花了這么大的篇幅進行實驗來說明了兩種限制案例,以及 Unsafe 的解決方案,還需要有實際的應(yīng)用場景佐證 Unsafe#allocateInstance 的價值。我簡單列舉兩個場景:
序列化框架在使用反射無法創(chuàng)建對象時,可以嘗試使用 Unsafe 創(chuàng)建,作為兜底邏輯。 獲取包級別保護的類,再借助于反射機制,可以魔改一些源碼實現(xiàn)或者調(diào)用一些 native 方法,此法慎用,不建議在生產(chǎn)使用。
示例代碼:動態(tài)修改堆外內(nèi)存限制,覆蓋 JVM 啟動參數(shù):-XX:MaxDirectMemorySize
????private?void?hackMaxDirectMemorySize()?{
????????try?{
????????????Field?directMemoryField?=?VM.class.getDeclaredField("directMemory");
????????????directMemoryField.setAccessible(true);
????????????directMemoryField.set(new?VM(),?8L?*?1024?*?1024?*?1024);
????????????Object?bits?=?Util.unsafe.allocateInstance(Class.forName("java.nio.Bits"));
????????????Field?maxMemory?=?bits.getClass().getDeclaredField("maxMemory");
????????????maxMemory.setAccessible(true);
????????????maxMemory.set(bits,?8L?*?1024?*?1024?*?1024);
????????}?catch?(Exception?e)?{
????????????throw?new?RuntimeException(e);
????????}
????????System.out.println(VM.maxDirectMemory());
????}
總結(jié)
先大概介紹這三個 Unsafe 用法吧,已經(jīng)是我個人認(rèn)為比較常用的幾個 Unsafe 案例了。
Unsafe 這個東西,會用的人基本都知道不能瞎用;不會用的話,看個熱鬧,知道 Java 有這個機制總比不知道強對吧。當(dāng)然,本文也介紹了一些實際場景可能必須得用 Unsafe,但更多還是出現(xiàn)在各個底層源碼之中。
如果還有讀者想看到更多騷操作的話,歡迎轉(zhuǎn)發(fā)本文,閱讀過 1500,繼續(xù)加更一期,一鍵三連,這次一定。
