ByteBuffer, что является чистым способом определить, нужно ли его перевернуть

Question

Есть ли чистый безопасный способ обнаружения, если ByteBuffer нуждается в переворачивании?

У меня есть ByteBuffer, который используется для упаковки и распаковки структуры данных, а также для хранения байтов, которые должны быть упакованы/распакованы.

Однако, если операция записи только что была выполнена или операция чтения выполнена, или если ByteBuffer был передан моему коду, я не могу гарантировать, что буфер находится в режиме записи или режиме чтения без ручного управления позицией и ограничением ,

Частичные чтения и записи также могут быть добавлены к этой проблеме. Я принимаю соглашение о том, что буфер остается в режиме записи, и создается дубликат и переводится в целях чтения. Когда буфер передается в мой код, он проверяется вручную, а положение и предел устанавливаются так же, как и в режиме записи. Конечно, есть лучший способ.

Answer 1

Encapsulate его в объекте - что-то вроде следующего:

class FlippingByteBuffer { 
    ByteBuffer buffer; 
    boolean isInUse; 
    boolean/Enum mode; //Is it read or write? 
} 

Затем вы можете использовать его в коде:

//I'm about to read 
FlippingByteBuffer fbb =...; 
fbb.beginReading(); 
doSomething(fbb.getByteBuffer()); 
fbb.finishReading(); 

Таким образом, вы знаете, когда что-то происходит. Вы могли бы даже начать использовать Lock s, чтобы обеспечить чтение и запись друг друга и т. Д.

Если есть что-то среднее, вы вызываете что-то, и оно возвращается к вам), вы можете поместить свой FlippingByteBuffer в карту и/или поместить ее в ThreadLocal (ewww!) или сделать FlippingByteBuffer орудие ByteBuffer. То, что может иметь возможность автоматически переключаться между режимами (используя методы чтения и записи) в зависимости от того, что вы делаете.

Answer 2

Как идея, как обматывать ByteBuffer в другом классе? Этот класс может обновлять и поддерживать состояние, которое вы хотите, всякий раз, когда выполняете операции чтения или записи. Вы также можете реализовать блокировку или какой-либо другой механизм, чтобы сделать его потокобезопасным.

Answer 3

Я думаю, что причина, по которой он не является частью ByteBuffer, заключается в том, что понятие режимов «читать» и «писать» является частью вашей концепции ByteBuffer. Буфер может читать или писать в любое время, поэтому строго не существует в состоянии чтения/записи.

Как только я понял это, имело смысл, что мы отвечаем за реализацию нашего собственного отслеживания состояния чтения/записи.

Это такой распространенный случай использования, который nio должен реализовать, хотя ... тем более, что интерфейс ByteBuffer не расширяется.