ByteBuffer.allocate() vs. ByteBuffer.allocateDirect()

Question

A allocate() ou à allocateDirect() c'est la question.

Depuis quelques années, je me suis contenté de penser que puisque DirectByteBuffer sont un mappage direct de la mémoire au niveau du système d'exploitation, ce qui signifie que les appels d'entrée/sortie seraient plus rapides que les appels de sortie. HeapByteBuffer s. Jusqu'à présent, je n'ai jamais vraiment cherché à connaître les détails exacts de la situation. Je veux savoir lequel des deux types de ByteBuffer sont plus rapides et dans quelles conditions.

Answer 1

Il n'y a aucune raison de s'attendre à ce que les tampons directs soient plus rapides pour les accès. à l'intérieur de le jvm. Leur avantage vient lorsque vous les passez au code natif -- comme, le code derrière les canaux de toutes sortes.

Answer 2

étant donné que les DirectByteBuffers sont une mappage direct de la mémoire au niveau du système d'exploitation

Ils ne le sont pas. Il s'agit simplement de la mémoire normale du processus d'application, mais elle n'est pas soumise à la relocalisation pendant la GC de Java, ce qui simplifie considérablement les choses dans la couche JNI. Ce que vous décrivez s'applique à MappedByteBuffer .

qu'il serait plus rapide avec les appels get/put.

La conclusion ne découle pas des prémisses ; les prémisses sont fausses ; et la conclusion est également fausse. Elles sont plus rapides une fois que vous êtes dans la couche JNI, et si vous lisez et écrivez à partir de la même couche JNI. DirectByteBuffer ils sont mucho plus rapidement, car les données ne doivent jamais traverser la frontière JNI.