怎樣使set現程變得安全

總覽

如果直接使用Unsafe，則可能會導致JVM崩潰。 當您訪問尚未映射的內存頁面并且在Unix上的結果是SIGSEG（如果訪問頁面0）或SIGBUS（如果您訪問另一個未映射的頁面）時，會發生這種情況。

使用MethodHandles

用MethodHandle包裝不安全的方法是一種可能的解決方案。 您可以將代碼添加到“方法句柄”以檢查零頁面訪問。 例如unsigned_ptr <4096。您應將其添加到MethodHandle的原因是它可以使優化檢查變得更容易。

缺點是

• 您必須使用MethodHandles，它會使語法復雜化，并掩蓋您的實際工作。
• 如果你不這樣做是行不通的
• 它不涵蓋總線錯誤，也不涵蓋總線錯誤，因為整個應用程序的映射很復雜，并且可以隨時在任何線程中更改。
• 優化界限檢查需要對優化器進行一些工作，這有待證明。

使用信號

如果已經有某種方法可以在硬件中做到這一點，那就可以了。 CPU已檢查您嘗試訪問的頁面是否有效，如果該頁面不在高速緩存中，它將引發中斷。 如果操作系統無法找到/創建此高速緩存未命中的映射，則此中斷將變為信號。

如果JVM中已經只有一個信號處理程序，并且確實存在，那就是產生崩潰報告的原因。

如果只有某種方式，中斷處理程序可以將錯誤或異常觸發回觸發它的代碼。 就像Thread.currentThread（）。stop（e）; （你明白了）

優點

• 由于CPU已經完成了檢查，因此不需要其他工作。
• 對優化器的最小更改（如果有）。
• 潛在地適用于從各種來源產生的信號。
• 使用信號是捕獲Java之前的運行時錯誤的一種成熟/較老的技術方法。

缺點

• 單一處理可能是一個停下來的操作（目前無法在Java中對其進行基準測試）
• 即使不是，觸發錯誤時它的成本也可能更高。
• 您將不得不更改傳統上未更改的信號處理程序。 即，有更多的經驗來改變優化器。

可能引發的異常

可能會引發新的異常，但是我建議重用現有的異常。

訪問頁面0 – NullPointerException

訪問頁面0（不僅僅是訪問NULL指針）將觸發SIGSEG。 NPE是根據C對NULL指針的訪問來命名的，與訪問引用相比，使用NPE訪問NULL指針可能更明顯。 也就是說，由于Java沒有指針，它可能被稱為NullReferenceException。

無效的訪問– IndexOutOfBoundsException

其他候選對象包括BufferUnderflowException（如果您的頁面缺少映射區域），BufferOverflowException（如果您的頁面沒有映射區域）。

這些都是它們的共同點是它們是RuntimeException（s）。 如果引發了一個自定義的，更具描述性的異常，則RuntimeException可能與拋出的現有throwables一致。

結論

使性能最大化的常見技巧是： 不要用Java編寫系統已經為您完成的事情。 在Chronicle中，我們使用OS對磁盤執行異步持久化，并且比再次用Java編寫持久性持久化更有效，更可靠。 同樣，如果重新使用CPU和OS提供的功能，則捕獲和處理無效的內存訪問將更加高效和健壯。

一般來說，當每個操作系統做不同的事情以支持跨平臺兼容性時，您都將重新編寫操作系統功能，但是這樣做僅需最低要求。 這就是為什么Java沒有線程調度程序，并且相對而言，它幾乎無法控制線程的運行方式。

虛擬內存處理非常古老且標準，以至于主要平臺的工作方式基本相同。

翻譯自: https://www.javacodegeeks.com/2014/06/making-unsafe-safer.html

怎樣使set現程變得安全

總結

以上是生活随笔為你收集整理的怎样使set现程变得安全_使不安全变得更加安全的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。