我期待使用Chronicle Map作为数据存储/数据缓存，并打算与在同一个盒子上运行的其他JVM进程共享它，以减少每个其他JVM进程的内存占用，否则每个JVM进程将加载相同的内容数据。每当在数据存储区中添加或删除条目时，是否可以在每个JVM进程上获得通知？它真的会减少内存占用吗？因为，每个JVM进程无论如何都要创建一些域对象。
我查看了API和文档，但对我来说如何实现我的用例并不是很清楚。 MapMethods和remoteOperations最接近它，也许是最佳选择。我想知道什么是获得预期功能的正确方法，或者我离开了。
如果我在正确的轨道上，那么，我猜测只需要在观察者一侧而不是在主数据存储上提供mapMethods / remoteOperations。我是对的吗？
答案 0 :(得分：2)
真的会减少内存占用吗？因为，每个JVM进程无论如何都要创建一些域对象。
是的，确实如此。首先，您可以使用flyweight模式来避免实际的序列化/反序列化并直接访问堆外内存，请参阅example in the Chronicle Map tutorial和Chronicle Values。
但即使您发现这不可能或实现起来太复杂，您也可以在反序列化对象以在JVM中访问它们时通过map.getUsing()或更好的inside context sections重用对象，其中对象重用是自动的（如果值类型序列化器确实允许重用对象）。
但即使你不能重用价值对象，e。 G。因为它们像String一样是不可变的，所以在反序列化堆外内存时创建的对象很可能是短生命的，并且不会从年轻代升级，GC会有效地收集它们，你将有效地重用内存。如果你有每个JVM映射，则每个副本永久驻留在不重用的内存中。
因此，在任何情况下，在JVM之间共享Chronicle Map对于机器中的整体内存使用以及性能都是一件好事。
是否可以在数据存储区中添加或删除条目时获取每个JVM进程的通知？
开源版本无法开箱即用。 order这样的功能是可能的。您提到的remoteOperations也是如此，此功能在开源支持中不再适用。但是，remoteOperations并不完全符合您的需要。
修改 请注意，根据您的吞吐量要求和更新频率，您可以相对轻松地自行实现此功能，方法是将您对Chronicle Map所做的udpates复制到多播IPC，如Chronicle Queue或Aeron IPC，然后将其读入其他JVM。您只能复制没有值的更新密钥。
如果您的地图更新频率如此之高（每秒数百次更新及以上），此解决方案可能会比编年史地图所能提供的更糟糕（甚至无法正常运行）＃34;您无法真正处理所有更新，并希望通过在已经对相同密钥进行较新更新时忘记某些密钥的陈旧更新来自然地限制事件。但在你的情况下，根本不需要这样做。
MapMethods和remoteOperations最接近它，也许是最佳选择。我想知道什么是获得预期功能的正确方法，或者我离开了。
MapMethods的目标很简单 - 使用Chroncile Map的上下文和较低级别的操作覆盖Map方法的默认命令。它与远程通信，事件和听力没有任何共同之处。您可以覆盖MapMethods.put() e。 G。添加一些日志记录或事件通知，但您可以在每次调用chronicleMap.put()之后通过记录或通知来执行此操作，结果几乎相同。
RemoteOperations允许重新定义在某个节点上放置/删除/更新条目并且此事件到达另一个节点时应发生的操作。默认情况下，如果事件的时间戳晚于在接收节点中具有事件键的条目的最后一次更新的时间戳，则事件在接收器节点上重新播放。即＆＃34;最后写胜利＃34;。但它可以覆盖定义不同的策略，即。即如果值包含一些计数，则写入具有最高计数的值。