在我的实现中，我需要调用一个需要提供令牌的 api。 该令牌的有效期为 15 分钟。 所以我正在实现的是一个内存缓存，缓存在 13 分钟后过期，因此缓存过期后将重新生成令牌，然后存储在缓存中
以下是创建令牌的调用包含在缓存中的代码：
<sub-flow name="common-root-get-access-token-subflow">
<ee:cache doc:name="access token cache" cachingStrategy-ref="Token_Caching_Strategy">
<flow-ref doc:name="Call token endpoint" name="create token" />
</ee:cache>
<set-variable value="#[payload.access_token]" doc:name="assign access token"
variableName="rootAccessToken" />
</sub-flow>
缓存定义如下：
<ee:object-store-caching-strategy name="Token_Caching_Strategy" doc:name="Caching Strategy"
keyGenerationExpression="abcd">
<os:private-object-store alias="tokenCache" persistent="false" maxEntries="1"
entryTtl="13" entryTtlUnit="MINUTES" expirationInterval="13"
expirationIntervalUnit="MINUTES"/>
</ee:object-store-caching-strategy>
通过上述配置观察到的是： #1 缓存似乎在 23 分钟后过期，而不是 13 。所以根据这篇文章，我认为缓存的持续时间是 13 分钟 TTL + 间隔 13 分钟 = 26 分钟（参考这里）
#2 接下来尝试使用 ttl = 3 分钟，间隔 = 2 分钟
缓存每 4 分钟就会过期（这里我假设由于前 2 分钟的 2 分钟间隔，缓存尚未过期，但在第二个 2 分钟间隔 = 第 4 分钟，缓存已过期，因此缓存即将过期）
#3 接下来尝试使用 ttl = 3 分钟，间隔 = 1 分钟
缓存每 4 分钟过期一次...... 认为缓存的实际寿命是 3 分钟，但检查它的间隔是 1 分钟 所以理想情况下，缓存应该在第 3 分钟结束时过期，但可能是因为缓存的寿命为 3 并且检查 3 的时间与 Mule 的时间一致，所以缓存可能不会在第 3 分钟过期 相反，在 1 分钟 = 第 4 分钟后进行下一次检查时，缓存即将过期，看起来像 ........
#4 接下来尝试使用 ttl = 3 分钟，间隔 = 3 分 5 秒
缓存似乎每 6 分 5 秒就会过期，而不是在我预期的每 3 分 5 秒后过期......
#5 接下来尝试使用 ttl = 3 分钟，间隔 = 1 分 5 秒
在这种情况下，它似乎正如我所期望的那样，缓存大约每 3 分钟和 5-15 秒之间就会过期
所以我的理解是，TTL 定义了缓存的实际寿命，但是缓存实际过期的时间是由定义的时间间隔决定的
#5 好像符合我的预期
#1 也可能是相同的，因为 TTL 和间隔是 13 分钟，Mule 可能不会在第 13 分钟而是在下一个间隔（13 + 13 = 26 分钟）从缓存中删除对象
#2 和 #3 也与上面一致
#4 似乎是一个异常值，我不知道为什么？ 另外，参考链接here似乎表明缓存将在 ttl + 间隔后过期
我的环境是使用 Java 8 的 Mule 4.4.6 运行时，并且正在使用 Studio 7.16
有人可以确认缓存过期的方式吗？ 如果我的令牌应该在 15 分钟内过期，我可以计划在 13 分钟后通过保持 TTL = 12 分 30 秒和间隔 = 1 分钟来使我的缓存过期吗？
Edit1尝试启用缓存调试日志，但对我期望某种后台线程运行并被记录感到失望（就像垃圾收集器线程，它会在指定的时间间隔运行并指定缓存是否是候选者）是否过期）
是的，你说得对。 ttl 决定每个单独条目的实际寿命。
expirationIntervalentryTtlexpirationIntervalentryTtl配置 TTL = 12 分 30 秒，间隔 = 1 分钟应该可以正常工作。您预计钥匙的停留时间最长为 13 分 30 秒，至少为 12 分 30 秒。
根据您对#1、#2、#3 的解释，我不明白#4 为何是异常值。 ttl 为 3 分钟，间隔为 3 分 5 秒，因此条目的活动时间最长为 6 分 5 秒