爲什麼無法將數據直接讀入地址空間而不是DirectByteBuffer

Question

我知道，對於I/O，直接字節緩衝區在本機堆上分配內存，而ByteBuffer在Java堆上分配內存，因此我們需要從中複製數據java堆到本地堆的I/O操作。

所以我的問題是，

是JVM的地址空間的直接ByteBuffer部分機堆？

如果不是的話爲什麼操作系統需要本地堆從套接字讀取數據？ 爲什麼不能直接從scoket讀取數據到JVM的地址空間？或請求進程的地址空間。

我的目標：我是電子工程師。最近開始在java上開發一個需要最小延遲的項目。我有各種選項，多線程，jvm調優。這些問題是從我的分析中產生的，我會考慮這些選擇。

Answer 1

本地JVM的地址空間的直接bytebuffer部分的堆？

是的。

它只是在用於java對象並由GC管理的地址範圍之外。

因爲我們需要將數據從java堆複製到本地堆以進行I/O操作。

如果您使用的是二進制數據，您可以將其保存在DBB中，並使用訪問器方法迭代其字節。這樣，只有您訪問的字節將被臨時複製。非直接BB的優勢在於您可以直接訪問其支持byte[]陣列。但是如果你不需要，那麼在某些情況下DBB可以更快。

可能的情景：

使用BB - >複製到本地
使用DBB - >沒有複製需要
使用Java對象 - >連載至BB - >複製到本地
使用Java對象 - >連載到DBB - >沒有額外的副本需要

在這些情況下，你會注意到使用DBB減少了複製。

這裏有一個其中它不：

使用BB - >通過下面的陣列，以期待byte[]
使用DBB的方法 - >拷貝爲byte [] - >傳遞到方法

在那些該方法需要重寫爲接受字節緩衝區。

最近開始在java上開發一個需要最小延遲的項目。我有各種選項，多線程，jvm調優。這些問題是從我的分析中產生的，我會考慮這些選擇。

你真的不應該擔心這樣的低級細節。在優化之前進行測量。稍後您需要時，從BB切換到DBB是微不足道的。