Mic*_*wan 5 java memory garbage-collection bytebuffer terracotta
我正在探索帮助我的内存密集型应用程序的选项,在这样做时我遇到了Terracotta的BigMemory.从我收集的内容来看,它们利用了非垃圾收集的堆外"本机内存",显然由于序列化/反序列化问题,这比堆存储慢大约10倍.在阅读BigMemory之前,我从未听说过正常JNI之外的"本机记忆".尽管BigMemory是一个值得进一步考虑的有趣选项,但如果可以绕过序列化问题,我会对本机内存可以实现的内容感到好奇.
ByteBuffer当没有序列化问题时(例如,如果我将它与巨大的比较),Java本机内存是否比传统堆内存更快(我认为这需要对象？byte[])？或者做垃圾收集的变幻莫测等让这个问题无法回答？我知道"测量它"是一个常见的答案,但我担心我不会建立一个代表性的测试,因为我还不太了解本机内存在Java中是如何工作的.
直接内存在执行 IO 时速度更快，因为它避免了数据的一份副本。然而，对于 95% 的应用程序，您不会注意到差异。
您可以将数据存储在直接内存中，但它不会比存储数据 POJO 更快。（或者安全、可读或可维护）如果您担心 GC，请尝试提前创建对象（必须是可变的）并重用它们而不丢弃它们。如果你不丢弃你的物品，就没有什么可以收集的。
当不存在序列化问题时（例如，如果我将其与一个巨大的 byte[] 进行比较），Java 本机内存是否比传统堆内存更快（我认为这需要 ByteBuffer 对象？）？
如果您使用非字节，则直接内存可能比使用 byte[] 更快，因为int它可以读取/写入整个四个字节，而无需将数据转换为字节。然而，它比使用 POJO 慢，因为它必须对每次访问进行边界检查。
或者垃圾收集等变幻莫测的行为是否使这个问题无法回答？
速度与GC无关。GC 仅在创建或丢弃对象时起作用。
顺便说一句：如果您最大限度地减少丢弃的对象数量并增加 Eden 大小，则可以防止长时间（例如一整天）发生少量收集。