假設我已經映射了一個記憶體區域[0, 1000]，現在我有MappedByteBuffer。
假設每個執行緒訪問緩沖區的不同部分，我可以在不鎖定的情況下從多個執行緒同時讀寫這個緩沖區。T1 [0, 500), T2 [500, 1000]?
如果上述情況屬實，是否可以確定為多個執行緒創建一個大的緩沖區，還是為每個執行緒創建較小的緩沖區更好？
uj5u.com熱心網友回復：
詳細介紹：
如果你想學習如何自己回答這些問題，請查看他們的實作源代碼：
現在情況變得有點復雜了：
當你想分配一個 MappedByteBuffer 時，你會得到一個- HeapByteBuffer。https://github.com/himnay/java7-sourcecode/blob/329bbb33cbe8620aee3cee533eec346b4b56facd/java/nio/HeapByteBuffer.java
- 或者一個DirectByteBuffer。https://github.com/himnay/java7-sourcecode/blob/329bbb33cbe8620aee3cee533eec346b4b56facd/java/nio/DirectByteBuffer.java
你也可以簡單地下載你的Java版本的源代碼包，并在你的IDE中附加它們，這樣你就可以在開發和除錯模式下看到代碼，而不必瀏覽互聯網頁面。這就容易多了。
簡短的（不完整的）回答：
它們中的任何一個都不能保證對多執行緒的安全。- 因此，如果你需要調整 MappedByteBuffer 的大小，你可能會得到陳舊甚至糟糕（ArrayIndexOutOfBoundsException）的訪問
- 如果你需要調整 MappedByteBuffer 的大小，你可能會得到陳舊甚至糟糕（ArrayIndexOutOfBoundsException）的訪問 如果大小是恒定的，那么就你的要求而言，你可以依靠任一實作來實作 "執行緒安全"。
byte[]byte[] hb緩沖區，- 但不使用它
- 而是創建和管理它自己的Buffer
這一設計缺陷來自于這些類的逐步開發（它們并不是在同一時間計劃和實施的），以及包的可見性問題，導致實施的依賴性/層次性的顛倒。
現在說說真正的答案：
如果你想做正確的面向物件的編程，除非完全需要，否則你不應該共享資源。 這尤其意味著每個執行緒都應該擁有自己的緩沖區。擁有一個全域緩沖區的優勢：唯一的 "優勢 "是減少額外物件參考的額外記憶體消耗。但這一影響是非常小的（甚至不會對您的應用程式的 RAM 消耗產生 1:10000 的變化），您將永遠不會注意到它。到處都有許多其他的物件因各種奇怪的（Java）原因而被分配，這是你所關心的最少的。此外，你將不得不引入額外的資料（索引邊界），這將進一步減少 "優勢"。
擁有獨立緩沖區的最大優勢：
- 你將永遠不需要照顧指標/索引的算術 。
-
- 你將永遠不必照顧指標/索引的算術
- 特別是當你在任何時候都需要更多的執行緒時
。
- Java在訪問每個陣列（在正常的堆陣列上，如
byte[]）之前，總是會檢查它，這正是為了防止副作用
- 回想一下：曾幾何時，作業系統邁出了一大步，引入了線性地址空間，這樣程式就不必關心它們在硬體RAM中的加載位置。
結論：
如果你想有一個非常糟糕的設計選擇--這將使以后的生活變得更加困難--你將使用一個全域緩沖區。
如果你想用正確的OO方式來做，就把這些緩沖區分開。沒有錯綜復雜的依賴關系和副作用問題。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/325326.html
標籤：
上一篇：為Asyncio添加多執行緒層