内存屏障保证数据缓存的一致性。但是，它能保证TLB的一致性吗？
我发现一个问题：在线程之间传递 MappedByteBuffer 时，JVM（java 7 update 1）有时会因内存错误（SIGBUS、SIGSEG）而崩溃。
e.g.
final AtomicReference<MappedByteBuffer> mbbQueue = new AtomicReference<>();
// in a background thread.
MappedByteBuffer map = raf.map(MapMode.READ_WRITE, offset, allocationSize);
Thread.yield();
while (!inQueue.compareAndSet(null, map));
// the main thread. (more than 10x faster than using map() in the same thread)
MappedByteBuffer mbb = inQueue.getAndSet(null);
如果没有 Thread.yield()，我偶尔会在 force()、put() 和 C 的 memcpy() 中崩溃，所有这些都表明我试图非法访问内存。使用 Thread.yield() 我没有遇到问题，但这听起来不像是一个可靠的解决方案。
有人遇到过这个问题吗？ TLB 和内存屏障有任何保证吗？
编辑：操作系统是 Centos 5.7，我已经看到了 i7 和双 Xeon 机器上的行为。
我为什么要这样做？因为写入消息的平均时间为 35-100 ns，具体取决于长度，并且使用普通 write() 的速度没有那么快。如果我在当前线程中进行内存映射和清理，则需要 50-130 微秒，而使用后台线程来执行此操作，主线程交换缓冲区大约需要 3-5 微秒。为什么我需要交换缓冲区？因为我正在写入许多 GB 的数据，而 ByteBuffer 的大小不能为 2+ GB。
映射是通过 mmap64 (FileChannel.map) 完成的。当访问该地址时，将出现页面错误，内核将为您读取/写入该地址。 mmap期间不需要更新TLB。
TLB（所有 cpu 的）在 munmap 期间未验证，这是通过 MappedByteBuffer 的最终确定来处理的，因此 munmap 的成本很高。
映射涉及大量同步，因此地址值不应被破坏。
您有机会通过 Unsafe 尝试一些奇特的东西吗？
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
