Java 是 Big-Endian；网络堆栈是 Big-Endian； Intel/AMD (基本上我们所有的计算机)和 ARM CPU(最常见的 Android 和 iOS 芯片)也都是小端。
考虑到所有这些，如果我为不同的用途分配一个直接的 ByteBuffer，总是尝试匹配本地交互的字节顺序是个好主意吗？
更具体地说:
- 网络缓冲区:保持大端。
- 文件缓冲区(在 x86 上):Little-Endian。
- OpenGL/ native 进程缓冲区:Little-Endian。
等等……
我问这个是因为我从来没有想过我的 ByteBuffer 的 Endian-ness，但是在看到一些 other questions 之后在 SO 和 performance impact 上它可以拥有，这似乎是值得的，或者至少是我在使用 ByteBuffers 时应该更加注意的事情。
或者担心我缺少并想知道的字节顺序可能有不利的一面？
最佳答案
它在您引用的文章中指出差异非常小。 (可能没有)
引用的结果并未显示一致的改进，使用最新的 JVM 可能会缩小差距。
- 当我启用“ native 字节顺序”时(如果机器使用不同的“endian”约定，这实际上是不安全的):
mmap: 1.358 bytebuffer: 0.922 regular i/o: 1.387
- 当我注释掉顺序语句并使用默认的大端顺序时:
mmap: 1.336 bytebuffer: 1.62 regular i/o: 1.467
有一个衡量差异，但它在事物的整体方案中很小。如果您希望它快得多，我发现唯一有很大不同的选项是直接使用 Unsafe，在这种情况下，只有 native 排序可用。
即便如此，它也只对延迟最敏感的应用程序有帮助。
Unsafe 加上代码和注释更加有趣。 ;)
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/misc/Unsafe.java
关于java - 设置 ByteBuffer 顺序(取决于缓冲区使用)是安全/良好的优化吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9279725/