就其线程模型而言，hazelcast 如何执行映射条目驱逐？答案

【问题标题】：How does hazelcast perform map entry eviction, in terms of its threading model?就其线程模型而言，hazelcast 如何执行映射条目驱逐？
【发布时间】：2016-02-21 18:13:24
【问题描述】：

我了解 hazelcast 配置中的 <min-eviction-check-millis> 定义了在检查此地图的分区是否可驱逐之前应该经过的最短时间（以毫秒为单位）。因此，在每个配置的时间间隔内，都会根据配置的驱逐策略在地图中执行驱逐。我有以下与该领域相关的问题。

第一季度。驱逐操作是否在操作线程上运行？

第二季度。驱逐操作会锁定它正在处理的整个分区吗？

第三季度。如果我要遵循 100 毫秒的默认值（我认为这是一个非常小的值），我是否需要预期任何性能损失。

第四季度。在以下场景中，驱逐操作多久执行一次。

<map name="employees">
    <in-memory-format>BINARY</in-memory-format>
    <backup-count>1</backup-count>
    <max-idle-seconds>1800</max-idle-seconds>
    <eviction-policy>NONE</eviction-policy>
    <time-to-live-seconds>0</time-to-live-seconds>
    <min-eviction-check-millis>1000</min-eviction-check-millis>
    <max-size>0</max-size>
    <eviction-percentage>0</eviction-percentage>
    <merge-policy>com.hazelcast.map.merge.PutIfAbsentMapMergePolicy</merge-policy>

</map>

请注意，虽然没有配置驱逐策略和百分比，但最大空闲时间设置为 1800 秒。

对上述问题的回答将帮助我就在大规模部署中用于这些配置的值做出明智的决定。

【问题讨论】：

标签： java hazelcast distributed-caching distributed-cache hazelcast-imap

【解决方案1】：

min-eviction-check-millis 是关于 max-size 策略和由于 max-size 驱逐的属性。如果你设置 min-eviction-check-millis=0;然后分区线程将检查每次更新的大小。如果你设置 min-eviction-check-millis=1000;如果先前的检查早于 1 秒，则分区线程将检查更新的大小。

如果您希望您的地图更严格地遵守最大尺寸政策，请将其设置为 0。但每次更新时都会产生检查尺寸的开销。

第一季度。驱逐操作是否在操作线程上运行？

它在分区线程上运行。分区线程执行基于分区的操作（map.put、map.get、map.remove 等）。

第二季度。驱逐操作会锁定它正在处理的整个分区吗？

不是显式锁。但是当分区线程执行驱逐操作时，该分区上的其他操作会被阻塞。

第三季度。如果我要遵循 100 毫秒的默认值（我认为这是一个非常小的值），我是否需要预期任何性能损失。

这是一个大小检查，但是是的，这是一个开销。如果您允许您的地图超过最大大小；那么你可以设置更高的值。

第四季度。在以下场景中，驱逐操作多久执行一次。

您尚未在此配置中设置 eviction-policy。所以 max-size 不会被检查。 min-eviction-check-millis 或 max-size 在这里不起作用。

max-idle-seconds（也是 ttl）是另一回事。我们称之为过期。每个 get 操作首先检查条目是否过期。但也定期；一些条目是随机选择的，并检查它们是否过期。过期的条目被删除。

【讨论】：