我期待将 Chronicle Map 用作数据存储/数据缓存，并打算与在同一机器上运行的其他 JVM 进程共享它，以减少每个其他 JVM 进程的内存占用，否则每个 JVM 进程将加载相同的数据。每当从数据存储中添加或删除条目时，是否可以获得有关每个 JVM 进程的通知？它真的会减少内存占用吗？因为，每个 JVM 进程无论如何都会创建一些域对象。
我查看了 API 和文档，但我不太清楚如何实现我的用例。MapMethods 和 remoteOperations 最接近它，也许是要走的路。我想知道获得预期功能的正确方法是什么，或者我是否有路要走。
如果我走在正确的轨道上，那么我猜测 mapMethods/remoteOperations 只需要在观察者端提供，而不是在主数据存储上。我对么？
它真的会减少内存占用吗？因为，每个 JVM 进程无论如何都会创建一些域对象。
是的。首先，您可以使用享元模式来避免实际的序列化/反序列化并直接访问堆外内存，请参阅Chronicle Map 教程和Chronicle Values中的示例。
但是，即使您发现这不可能或实现起来太复杂，您也可以在反序列化对象时重用对象，以便在 JVM、 viamap.getUsing()或更好的在对象重用是自动的上下文部分中访问它们（如果值类型序列化程序确实允许重用对象）。
但是即使你不能重用值对象，例如因为它们是不可变的String，当你反序列化堆外内存时创建的对象很可能是短暂的，不会从年轻代中提升，GC 会有效地收集它们并且您将有效地重用内存。而如果您有每个 JVM 映射，则每个副本都永久驻留在未重用的内存中。
所以无论如何，在 JVM 之间共享一个 Chronicle Map 对机器的整体内存使用和性能来说都是一件好事。
每当从数据存储中添加或删除条目时，是否可以获得有关每个 JVM 进程的通知？
在开源版本中不可能开箱即用。可以订购这样的功能。您提到的 remoteOperations 也是如此，该功能不再在开源支持中。但是，remoteOperations 并不是您的案例所需要的。
编辑 请注意，根据您的吞吐量要求和更新频率，您可以通过将制作到 Chronicle Map 的 udpate 复制到Chronicle Queue或Aeron IPC等多播 IPC ，然后在其他 JVM 中读取它们来相对轻松地实现这一点。您只能复制更新后的键，而不复制值。
如果您的地图更新频率如此之高（每秒数千次更新及以上）以至于您无法真正处理所有更新并且想要当已经对同一密钥进行了更新时，通过忘记对某些密钥的过时更新来自然地限制事件。但在你的情况下，这可能根本不需要。
MapMethods 和 remoteOperations 最接近它，也许是要走的路。我想知道获得预期功能的正确方法是什么，或者我是否有路要走。
MapMethods 的目标很窄——Map使用 Chroncile Map 的上下文和较低级别的操作覆盖 's 方法的默认实施。它与远程通信、事件和监听没有任何共同之处。您可以覆盖MapMethods.put()例如添加一些日志记录或事件通知，但您可以通过在每次调用后记录或通知来执行此操作，chronicleMap.put()结果几乎相同。
RemoteOperations 允许重新定义在某个节点上放置/删除/更新条目并且此事件到达另一个节点时应该发生的操作。默认情况下，事件在接收方节点上重新播放，如果它的时间戳晚于接收方节点中具有事件键的条目的最后更新时间戳，即“最后一次写入获胜”。但它可以被覆盖以定义不同的策略，即如果值包含一些计数，则写入计数最高的值。