Caffeine JCache 适配器 JSR-107 一致性审计从 TCK 盲区到全规范面覆盖的工程实践【免费下载链接】caffeineA high performance caching library for Java项目地址: https://gitcode.com/gh_mirrors/ca/caffeineJSR-107JCache1.1.1 规范定义了 Java 缓存的标准 API而 Caffeine 通过jcache/模块提供了完整的适配实现。本文讲解仓库中audit-jcache-conformance审计技能的核心方法如何对一个 JCache 适配器执行全规范面A–N 十四域的一致性差分审计识别 TCK 看不见的事件流与统计量偏差并用 parity-matrix 测试把结论钉死在回归防线中。读完本文你将掌握规范文本 → TCK → RI → 生态实现 → Caffeine 内部同级路径五级证据阶梯以及一套可复用的审计产出模板。为什么 TCK 是下限而不是验证标准审计文档开篇就点明了这套方法论的动机TCK 经常只断言可观察的终态containsKey/get而不是事件流CREATED/UPDATED/EXPIRED/REMOVED或统计量CachePuts、命中/未命中、移除、驱逐。这意味着两个事件与计数都不同的实现可以同时通过 TCK。这一点在该适配器近期修复的真实缺陷中得到印证零创建过期zero-creation-expiry产生幻影CREATEDgetExpiryForCreation() Duration.ZERO时条目本不应被存储也不应发布 CREATED零更新过期zero-update-expiry的put家族抑制UPDATED规范明确零更新过期应当先存储、立即过期且必须发布 UPDATED、计入 put。这两个 bug 恰好都活在 TCK 盲区里。因此审计在事件 / 统计量 / 过期 / 写穿write-through表面执行DEEP级差分而对规范其余部分执行COVERAGE级核查规范文本正确性 确认有测试钉住该条款一旦 COVERAGE 条款暴露出隐藏的 TCK 不可见事件或统计量立即升级为 DEEP 差分。该文档对应的常驻裁决、已接受差异与验证模式记录在 .claude/docs/jsr107-conformance.md审计前必须先读其适配器专属约定见 .claude/rules/jcache-adapter.md。审计触发时机与边界审计文档明确给出了何时运行清单对jcache/src/main中以下任一文件的修改之后CacheProxy、LoadingCacheProxy、EntryProcessorEntry/postProcess、EventDispatcher、过期逻辑、统计逻辑、写穿CacheWriter路径或按值存储store-by-value复制发布前作为一次完整的 1.1.1 复核每季度一次作为一致性基线当/audit-sibling-divergence同级路径分叉审计的 Group G2 发现需要裁决方向时——静态审计无法判定方向而且历史上猜错过零更新过期修复方向曾被静态审计推断反。同时它明确不负责适配器并发问题单线程规范差分之外的并发窗口live-view 与快照竞态、executor 线程上的义务配对、close/destroy 对称性分属/audit-subsystem-safety、/audit-memory-retention、/audit-lifecycle等技能。这是一个重量级审计需拉取规范、克隆/拉取生态实现、可能派生子审计器不适合日常 pre-commit 评审。Step 0装载规范与资源地图审计的第一步是读.claude/docs/jsr107-conformance.md——它是资源地图包含每个域对应的 RI/生态类位置、差分方法、parity 测试模式以及已解决分歧的目录不得重新标记。随后拉取实时规范文本DOC1ijduF_tmHvBaUS7VBBU2ZN8_eEBiFaXXg9OI0_ZxCrA curl -fsSL https://docs.google.com/document/d/$DOC/export?formattxt -o /tmp/jsr107_spec.txt获取后必须确认拉取的是真实规范grep 检查getExpiryForUpdate而非登录页。导出会重排排版因此引用规范一律按section 名称1.1.1 章节标题已按域列在下方矩阵中。同时在本机定位 TCK 源码find ~/.gradle/caches -name cache-tests-1.1.1-test-sources.jar # 以及 jcache/build/tck/ 目录本仓库中TCK 由 Gradle 测试套件tckTest驱动jcache/build.gradle.kts注册了独立的JvmTestSuite通过unzipTestKit任务把cache-tests-1.1.1解包到jcache/build/tck/并用系统属性把javax.cache.Cache指向com.github.benmanes.caffeine.jcache.CacheProxy、CacheManager指向CacheManagerImpl等。因此验证命令是:jcache:test与:jcache:tckTest两条都要跑——TCK 编码了单元测试抓不到的规范解释。Step 1构建规范面矩阵A–N审计要求走遍整个1.1.1 规范把每个规范性域映射到其规范章节、适配器代码与应投入的深度而不是只盯着写路径/过期家族——近期 bug 造成的近因偏差正是这个矩阵要纠正的。深度分配规则DEEP——TCK 未钉住事件流 / 统计量 / 过期时序可能掩盖真实分歧。必须跑完整差分Step 2并新增 parity-matrix 测试。COVERAGE——规范文本无歧义且 TCK 终态断言足够。确认 (a) 适配器符合规范文本(b) 有测试钉住它并引用测试名。一旦出现隐藏事件/统计量立即升级为 DEEP。完整矩阵如下原文表格完整继承#域1.1.1 章节深度验证要点A写操作 × 过期Expiry Policies;Statistics EffectsDEEPput/putAll/putIfAbsent/getAndPut/replace(K,V)/replace(K,V,V)/getAndReplace——创建 vs 更新的ZERO/ETERNAL/null过期CREATED/UPDATED发布CachePuts计数。全部同级路径内部一致。B读与访问Expiry Policies;Integration;Statistics EffectsDEEPget/getAll/containsKey/iterator——getExpiryForAccess的ZERO/null/有限值CacheHits/CacheMissescontainsKey 不得计数读穿加载按 get-未命中计而非 putC删除操作Cache Entry Listeners;Integration;Statistics EffectsDEEPremove(K)/remove(K,V)/getAndRemove/removeAll(keys)/removeAll()/clear()——REMOVED事件 oldValueremoveAll()计 removalsclear()不计对已过期条目的删除统计门控CacheWriter.deleteD条目处理器Entry Processors;Statistics EffectsDEEPinvoke/invokeAll——EntryProcessorEntry.Action状态机NONE→READ/CREATED/UPDATED/LOADED/DELETED对照 RIMutableEntryOperation逐操作事件 统计读穿getValue()计为 put已编目确认即可勿重报E事件Cache Entry ListenersDEEPCREATED/UPDATED/REMOVED/EXPIRED载荷isOldValueAvailable/getOldValue同步 vs 异步分发CacheEntryEventFilter每键顺序EventDispatcherCompletableFuture 链运行时注册/注销F统计Statistics Effects of Cache OperationsDEEP完整CacheStatisticsMXBean矩阵CacheHits/Misses/Gets/Puts/Removals/Evictions× 每个操作。失败的putIfAbsent/replace记账CacheEvictionsCaffeine 原生驱逐 → JCache 统计的桥无同级实现相同CacheStatisticsMXBean.clear()重置全部计数器与计时器平均值RI 三个均值都除以CacheGets其 put/remove 均值在无 get 时恒为 0G集成——写者IntegrationDEEP写穿CacheWriter.write/delete相对存储与事件/统计的顺序写者异常必须抑制事件与CachePuts增量writeAll/deleteAll部分失败的集合变异CacheWriterException包装H集成——加载者IntegrationDEEP读穿get/getAll/invokeloadAll的replaceExistingValues 完成监听器CacheLoaderException包装1.1.1CacheLoaderExceptionjavadoc 仍要求TCK 对get与loadAll都断言I按值存储Store-By-Value and Store-By-ReferenceCOVERAGE复制点put/get/iterator/事件载荷调用方变异隔离RISerializingInternalConvertervsRIReferenceInternalConverter。事件/统计路径若跳过复制则升级J类型ConfigurationCOVERAGEgetKeyType/getValueType强制错误类型put/get抛ClassCastExceptiongetCache(name, K, V)类型检查K配置ConfigurationCOVERAGEMutableConfiguration创建时快照FactoryCacheLoader/CacheWriter/ExpiryPolicy读穿/写穿/按值存储/统计/管理开关L生命周期Caching ProvidersCOVERAGEclose/isClosed→ 每个操作抛IllegalStateExceptionCacheManager的 create重复→CacheException/get/destroygetCacheNames不可变迭代器provider URI/类加载器/属性M管理Caching ProvidersMXBeansCOVERAGECacheMXBean属性JMXObjectName净化已编目运行时启停统计与管理N空值 / 对抗性输入方法 javadocCOVERAGE全 API 空 key/value/map/filter/processor 参数的NullPointerException契约范围边界规范中的注解章节CDI/Spring 的CacheResult等是适配器未实现的独立章节明确排除。Step 2运行差分DEEP 五级阶梯 COVERAGE 核查对每个DEEP域的每个角落按下述顺序执行直到参照行为无歧义规范文本——读/tmp/jsr107_spec.txt中管辖的 javadoc/表格。注意兄弟操作之间刻意不同的措辞创建 vs 更新是经典陷阱。TCK——找到测试并读它断言什么。只断言终态 → 无法裁决事件/统计问题继续。当 TCK 与规范 javadoc 冲突时TCK 优先见 .claude/rules/jcache-adapter.md。RI参考实现——读该域的 oracle 类资源地图每域点名一个RICache写/删路径、RICacheStatisticsMXBean、RICacheEventDispatcher、RICache.writeCacheEntry/deleteCacheEntry等。≥3 个生态实现——拉取文档点名的适配器文件.claude/docs/jsr107-conformance.md 的 provider 源码地图覆盖 cache2k、Coherence、Ehcache 2/3、Hazelcast、Infinispan逐个分类记录分歧。Caffeine 内部同级路径 parity——验证每个同级路径与参照行为一致且彼此一致。内部不一致是最高信号发现必有一方可证明是错的。对每个COVERAGE域确认适配器行为符合规范文本且有 TCK 或单元测试钉住——按名字引用测试。若唯一测试只断言终态、而条款隐藏事件/统计例如clear()是否触发REMOVED事件载荷上是否发生 store-by-value 复制把该角落升级为 DEEP并跑上面的阶梯。正确但未测试的 COVERAGE 条款是覆盖度发现不是通过。证据事件分发与条目处理器的实现印证以域 D/E 为例适配器源码与文档结论直接对应EntryProcessorEntryjcache/src/main/java/com/github/benmanes/caffeine/jcache/processor/EntryProcessorEntry.java实现了MutableEntry的 Action 状态机初始Action.NONEgetValue()在无值且配置了 loader 时触发读穿加载并把动作置为LOADED否则置为READsetValue按hasEntry区分CREATED/UPDATEDremove()把CREATED重置为NONE完全 no-op否则置为DELETED。这与文档表格读穿 getValue() / LOADED → miss 不计 put创建后删除 / CREATED → NONE → 完全 no-op一一对应。EventDispatcherjcache/src/main/java/com/github/benmanes/caffeine/jcache/event/EventDispatcher.java用注册 × 键粒度的ConcurrentMap维护每条 (listener, key) 的 CompletableFuture 链保证同键事件串行、不同键并行beginComputation/endComputation用线程局部 gate 把计算期间发布的事件暂存、提交后统一释放——这正是在变异 compute 内追加事件保持每键顺序但把监听器执行延后到计算结束的工程实现。子审计器的组织与防覆盖机制按域组各派生一个子审计器——写/读/删A–C、条目处理器D、事件E、统计F、集成加载写G–H、按值存储/类型/配置/生命周期/管理I–N——每个都以资源地图文档 拉取的规范为上下文且必须返回具体见证操作序列 → 分歧的事件/统计/终态或钉住该条款的测试。子代理读不到会话记忆必须把文档的分歧目录内联粘贴避免它们重新推导已知误报。关键纪律每个子审计器把报告写到组后缀路径.local/audits/model/audit-jcache-conformance-group.md绝不写规范路径——并行组都写audit-jcache-conformance.md会互相覆盖2026-07 那次运行因此丢失了两份组报告只能从 agent 转录中恢复。Step 3裁决并钉死对每个确认的真实分歧陈述规范文本、RI 行为、生态投票、Caffeine 内部 parity 结果。修复方向跟随规范 RI若静态发现假设了相反方向必须明说历史上发生过零更新过期修复方向与静态审计的猜测相反。以最小、外科手术式的改动实施修复然后新增parity-matrix 测试writeOp_*/readOp_*/removeOp_*覆盖每个同级操作断言它们产生相同的事件计数、统计增量与终态。TCK 不是回归防线parity 测试才是。仓库中现成的样板包括JCacheCreationExpiryTest.writeOp_absent_zeroCreationExpiry、JCacheUpdateExpiryTest.writeOp_present_zeroUpdateExpiry以及CacheProxyTest.invoke_readThroughLoad_recordsMissNotPut等均位于jcache/src/test/java/com/github/benmanes/caffeine/jcache/。运行:jcache:test和:jcache:tckTest——按 .claude/rules/jcache-adapter.md 的验证约定TCK 编码了单元测试遗漏的解释。更新 .claude/docs/jsr107-conformance.md 的目录与生态矩阵让下一次运行不必重复诉讼。对正确但未测试的 COVERAGE 条款记录为覆盖度缺口应补哪个测试而不是 bug。审计产出合并裁决报告由编排器而非子审计器写.local/audits/model/audit-jcache-conformance.md——跨组后缀报告的合并裁决——使用标准 .claude/docs/finding-taxonomy.md 模式severity / category / confidence / classification。报告必须以规范面覆盖矩阵领衔每个域 A–N → 深度 → 裁决conformant / divergence / coverage-gap→ 见证或钉住测试的引用。一次干净的运行必须显示每个域都被触达——干净意味着完整 1.1.1 表面都走过了而不是只走了近期 bug 的角落。随后是每条发现规范引用按章节名、RI 行为、生态投票、Caffeine 内部 parity 结果、见证操作 → 分歧的可观察行为、带依据的修复方向。没有规范/RI/生态背书方向的发现不算就绪——记为 escalated而不是 fix。实践要点小结先读资源地图.claude/docs/jsr107-conformance.md记录了已解决分歧避免重报.claude/rules/jcache-adapter.md是适配器裁决常驻约定。深度分级防近因偏差A–H 八个域是 DEEPI–N 六个域是 COVERAGECOVERAGE 出现隐藏事件/统计即升级。五级证据阶梯规范文本 → TCK 断言 → RI oracle → ≥3 生态实现 → Caffeine 内部 parity内部不一致是最高信号。parity 测试是回归防线TCK 只测终态事件流与统计量必须靠参数化 parity 测试钉死。双命令验证改一致性相关代码后:jcache:test与:jcache:tckTest必须都通过TCK 系统属性把标准javax.cache.*接口映射到本仓库的CacheProxy/CacheManagerImpl等实现类。产出结构化合并报告以 A–N 覆盖矩阵领衔每条发现带见证与方向依据子审计器必须写组后缀路径防止并行覆盖。【免费下载链接】caffeineA high performance caching library for Java项目地址: https://gitcode.com/gh_mirrors/ca/caffeine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/21 2:55:03 · 阅读 1.2k Caffeine JCache 适配器 JSR-107 一致性审计：从 TCK 盲区到全规范面覆盖的工程实践
Caffeine JCache 适配器 JSR-107 一致性审计从 TCK 盲区到全规范面覆盖的工程实践【免费下载链接】caffeineA high performance caching library for Java项目地址: https://gitcode.com/gh_mirrors/ca/caffeineJSR-107JCache1.1.1 规范定义了 Java 缓存的标准 API而 Caffeine 通过jcache/模块提供了完整的适配实现。本文讲解仓库中audit-jcache-conformance审计技能的核心方法如何对一个 JCache 适配器执行全规范面A–N 十四域的一致性差分审计识别 TCK 看不见的事件流与统计量偏差并用 parity-matrix 测试把结论钉死在回归防线中。读完本文你将掌握规范文本 → TCK → RI → 生态实现 → Caffeine 内部同级路径五级证据阶梯以及一套可复用的审计产出模板。为什么 TCK 是下限而不是验证标准审计文档开篇就点明了这套方法论的动机TCK 经常只断言可观察的终态containsKey/get而不是事件流CREATED/UPDATED/EXPIRED/REMOVED或统计量CachePuts、命中/未命中、移除、驱逐。这意味着两个事件与计数都不同的实现可以同时通过 TCK。这一点在该适配器近期修复的真实缺陷中得到印证零创建过期zero-creation-expiry产生幻影CREATEDgetExpiryForCreation() Duration.ZERO时条目本不应被存储也不应发布 CREATED零更新过期zero-update-expiry的put家族抑制UPDATED规范明确零更新过期应当先存储、立即过期且必须发布 UPDATED、计入 put。这两个 bug 恰好都活在 TCK 盲区里。因此审计在事件 / 统计量 / 过期 / 写穿write-through表面执行DEEP级差分而对规范其余部分执行COVERAGE级核查规范文本正确性 确认有测试钉住该条款一旦 COVERAGE 条款暴露出隐藏的 TCK 不可见事件或统计量立即升级为 DEEP 差分。该文档对应的常驻裁决、已接受差异与验证模式记录在 .claude/docs/jsr107-conformance.md审计前必须先读其适配器专属约定见 .claude/rules/jcache-adapter.md。审计触发时机与边界审计文档明确给出了何时运行清单对jcache/src/main中以下任一文件的修改之后CacheProxy、LoadingCacheProxy、EntryProcessorEntry/postProcess、EventDispatcher、过期逻辑、统计逻辑、写穿CacheWriter路径或按值存储store-by-value复制发布前作为一次完整的 1.1.1 复核每季度一次作为一致性基线当/audit-sibling-divergence同级路径分叉审计的 Group G2 发现需要裁决方向时——静态审计无法判定方向而且历史上猜错过零更新过期修复方向曾被静态审计推断反。同时它明确不负责适配器并发问题单线程规范差分之外的并发窗口live-view 与快照竞态、executor 线程上的义务配对、close/destroy 对称性分属/audit-subsystem-safety、/audit-memory-retention、/audit-lifecycle等技能。这是一个重量级审计需拉取规范、克隆/拉取生态实现、可能派生子审计器不适合日常 pre-commit 评审。Step 0装载规范与资源地图审计的第一步是读.claude/docs/jsr107-conformance.md——它是资源地图包含每个域对应的 RI/生态类位置、差分方法、parity 测试模式以及已解决分歧的目录不得重新标记。随后拉取实时规范文本DOC1ijduF_tmHvBaUS7VBBU2ZN8_eEBiFaXXg9OI0_ZxCrA curl -fsSL https://docs.google.com/document/d/$DOC/export?formattxt -o /tmp/jsr107_spec.txt获取后必须确认拉取的是真实规范grep 检查getExpiryForUpdate而非登录页。导出会重排排版因此引用规范一律按section 名称1.1.1 章节标题已按域列在下方矩阵中。同时在本机定位 TCK 源码find ~/.gradle/caches -name cache-tests-1.1.1-test-sources.jar # 以及 jcache/build/tck/ 目录本仓库中TCK 由 Gradle 测试套件tckTest驱动jcache/build.gradle.kts注册了独立的JvmTestSuite通过unzipTestKit任务把cache-tests-1.1.1解包到jcache/build/tck/并用系统属性把javax.cache.Cache指向com.github.benmanes.caffeine.jcache.CacheProxy、CacheManager指向CacheManagerImpl等。因此验证命令是:jcache:test与:jcache:tckTest两条都要跑——TCK 编码了单元测试抓不到的规范解释。Step 1构建规范面矩阵A–N审计要求走遍整个1.1.1 规范把每个规范性域映射到其规范章节、适配器代码与应投入的深度而不是只盯着写路径/过期家族——近期 bug 造成的近因偏差正是这个矩阵要纠正的。深度分配规则DEEP——TCK 未钉住事件流 / 统计量 / 过期时序可能掩盖真实分歧。必须跑完整差分Step 2并新增 parity-matrix 测试。COVERAGE——规范文本无歧义且 TCK 终态断言足够。确认 (a) 适配器符合规范文本(b) 有测试钉住它并引用测试名。一旦出现隐藏事件/统计量立即升级为 DEEP。完整矩阵如下原文表格完整继承#域1.1.1 章节深度验证要点A写操作 × 过期Expiry Policies;Statistics EffectsDEEPput/putAll/putIfAbsent/getAndPut/replace(K,V)/replace(K,V,V)/getAndReplace——创建 vs 更新的ZERO/ETERNAL/null过期CREATED/UPDATED发布CachePuts计数。全部同级路径内部一致。B读与访问Expiry Policies;Integration;Statistics EffectsDEEPget/getAll/containsKey/iterator——getExpiryForAccess的ZERO/null/有限值CacheHits/CacheMissescontainsKey 不得计数读穿加载按 get-未命中计而非 putC删除操作Cache Entry Listeners;Integration;Statistics EffectsDEEPremove(K)/remove(K,V)/getAndRemove/removeAll(keys)/removeAll()/clear()——REMOVED事件 oldValueremoveAll()计 removalsclear()不计对已过期条目的删除统计门控CacheWriter.deleteD条目处理器Entry Processors;Statistics EffectsDEEPinvoke/invokeAll——EntryProcessorEntry.Action状态机NONE→READ/CREATED/UPDATED/LOADED/DELETED对照 RIMutableEntryOperation逐操作事件 统计读穿getValue()计为 put已编目确认即可勿重报E事件Cache Entry ListenersDEEPCREATED/UPDATED/REMOVED/EXPIRED载荷isOldValueAvailable/getOldValue同步 vs 异步分发CacheEntryEventFilter每键顺序EventDispatcherCompletableFuture 链运行时注册/注销F统计Statistics Effects of Cache OperationsDEEP完整CacheStatisticsMXBean矩阵CacheHits/Misses/Gets/Puts/Removals/Evictions× 每个操作。失败的putIfAbsent/replace记账CacheEvictionsCaffeine 原生驱逐 → JCache 统计的桥无同级实现相同CacheStatisticsMXBean.clear()重置全部计数器与计时器平均值RI 三个均值都除以CacheGets其 put/remove 均值在无 get 时恒为 0G集成——写者IntegrationDEEP写穿CacheWriter.write/delete相对存储与事件/统计的顺序写者异常必须抑制事件与CachePuts增量writeAll/deleteAll部分失败的集合变异CacheWriterException包装H集成——加载者IntegrationDEEP读穿get/getAll/invokeloadAll的replaceExistingValues 完成监听器CacheLoaderException包装1.1.1CacheLoaderExceptionjavadoc 仍要求TCK 对get与loadAll都断言I按值存储Store-By-Value and Store-By-ReferenceCOVERAGE复制点put/get/iterator/事件载荷调用方变异隔离RISerializingInternalConvertervsRIReferenceInternalConverter。事件/统计路径若跳过复制则升级J类型ConfigurationCOVERAGEgetKeyType/getValueType强制错误类型put/get抛ClassCastExceptiongetCache(name, K, V)类型检查K配置ConfigurationCOVERAGEMutableConfiguration创建时快照FactoryCacheLoader/CacheWriter/ExpiryPolicy读穿/写穿/按值存储/统计/管理开关L生命周期Caching ProvidersCOVERAGEclose/isClosed→ 每个操作抛IllegalStateExceptionCacheManager的 create重复→CacheException/get/destroygetCacheNames不可变迭代器provider URI/类加载器/属性M管理Caching ProvidersMXBeansCOVERAGECacheMXBean属性JMXObjectName净化已编目运行时启停统计与管理N空值 / 对抗性输入方法 javadocCOVERAGE全 API 空 key/value/map/filter/processor 参数的NullPointerException契约范围边界规范中的注解章节CDI/Spring 的CacheResult等是适配器未实现的独立章节明确排除。Step 2运行差分DEEP 五级阶梯 COVERAGE 核查对每个DEEP域的每个角落按下述顺序执行直到参照行为无歧义规范文本——读/tmp/jsr107_spec.txt中管辖的 javadoc/表格。注意兄弟操作之间刻意不同的措辞创建 vs 更新是经典陷阱。TCK——找到测试并读它断言什么。只断言终态 → 无法裁决事件/统计问题继续。当 TCK 与规范 javadoc 冲突时TCK 优先见 .claude/rules/jcache-adapter.md。RI参考实现——读该域的 oracle 类资源地图每域点名一个RICache写/删路径、RICacheStatisticsMXBean、RICacheEventDispatcher、RICache.writeCacheEntry/deleteCacheEntry等。≥3 个生态实现——拉取文档点名的适配器文件.claude/docs/jsr107-conformance.md 的 provider 源码地图覆盖 cache2k、Coherence、Ehcache 2/3、Hazelcast、Infinispan逐个分类记录分歧。Caffeine 内部同级路径 parity——验证每个同级路径与参照行为一致且彼此一致。内部不一致是最高信号发现必有一方可证明是错的。对每个COVERAGE域确认适配器行为符合规范文本且有 TCK 或单元测试钉住——按名字引用测试。若唯一测试只断言终态、而条款隐藏事件/统计例如clear()是否触发REMOVED事件载荷上是否发生 store-by-value 复制把该角落升级为 DEEP并跑上面的阶梯。正确但未测试的 COVERAGE 条款是覆盖度发现不是通过。证据事件分发与条目处理器的实现印证以域 D/E 为例适配器源码与文档结论直接对应EntryProcessorEntryjcache/src/main/java/com/github/benmanes/caffeine/jcache/processor/EntryProcessorEntry.java实现了MutableEntry的 Action 状态机初始Action.NONEgetValue()在无值且配置了 loader 时触发读穿加载并把动作置为LOADED否则置为READsetValue按hasEntry区分CREATED/UPDATEDremove()把CREATED重置为NONE完全 no-op否则置为DELETED。这与文档表格读穿 getValue() / LOADED → miss 不计 put创建后删除 / CREATED → NONE → 完全 no-op一一对应。EventDispatcherjcache/src/main/java/com/github/benmanes/caffeine/jcache/event/EventDispatcher.java用注册 × 键粒度的ConcurrentMap维护每条 (listener, key) 的 CompletableFuture 链保证同键事件串行、不同键并行beginComputation/endComputation用线程局部 gate 把计算期间发布的事件暂存、提交后统一释放——这正是在变异 compute 内追加事件保持每键顺序但把监听器执行延后到计算结束的工程实现。子审计器的组织与防覆盖机制按域组各派生一个子审计器——写/读/删A–C、条目处理器D、事件E、统计F、集成加载写G–H、按值存储/类型/配置/生命周期/管理I–N——每个都以资源地图文档 拉取的规范为上下文且必须返回具体见证操作序列 → 分歧的事件/统计/终态或钉住该条款的测试。子代理读不到会话记忆必须把文档的分歧目录内联粘贴避免它们重新推导已知误报。关键纪律每个子审计器把报告写到组后缀路径.local/audits/model/audit-jcache-conformance-group.md绝不写规范路径——并行组都写audit-jcache-conformance.md会互相覆盖2026-07 那次运行因此丢失了两份组报告只能从 agent 转录中恢复。Step 3裁决并钉死对每个确认的真实分歧陈述规范文本、RI 行为、生态投票、Caffeine 内部 parity 结果。修复方向跟随规范 RI若静态发现假设了相反方向必须明说历史上发生过零更新过期修复方向与静态审计的猜测相反。以最小、外科手术式的改动实施修复然后新增parity-matrix 测试writeOp_*/readOp_*/removeOp_*覆盖每个同级操作断言它们产生相同的事件计数、统计增量与终态。TCK 不是回归防线parity 测试才是。仓库中现成的样板包括JCacheCreationExpiryTest.writeOp_absent_zeroCreationExpiry、JCacheUpdateExpiryTest.writeOp_present_zeroUpdateExpiry以及CacheProxyTest.invoke_readThroughLoad_recordsMissNotPut等均位于jcache/src/test/java/com/github/benmanes/caffeine/jcache/。运行:jcache:test和:jcache:tckTest——按 .claude/rules/jcache-adapter.md 的验证约定TCK 编码了单元测试遗漏的解释。更新 .claude/docs/jsr107-conformance.md 的目录与生态矩阵让下一次运行不必重复诉讼。对正确但未测试的 COVERAGE 条款记录为覆盖度缺口应补哪个测试而不是 bug。审计产出合并裁决报告由编排器而非子审计器写.local/audits/model/audit-jcache-conformance.md——跨组后缀报告的合并裁决——使用标准 .claude/docs/finding-taxonomy.md 模式severity / category / confidence / classification。报告必须以规范面覆盖矩阵领衔每个域 A–N → 深度 → 裁决conformant / divergence / coverage-gap→ 见证或钉住测试的引用。一次干净的运行必须显示每个域都被触达——干净意味着完整 1.1.1 表面都走过了而不是只走了近期 bug 的角落。随后是每条发现规范引用按章节名、RI 行为、生态投票、Caffeine 内部 parity 结果、见证操作 → 分歧的可观察行为、带依据的修复方向。没有规范/RI/生态背书方向的发现不算就绪——记为 escalated而不是 fix。实践要点小结先读资源地图.claude/docs/jsr107-conformance.md记录了已解决分歧避免重报.claude/rules/jcache-adapter.md是适配器裁决常驻约定。深度分级防近因偏差A–H 八个域是 DEEPI–N 六个域是 COVERAGECOVERAGE 出现隐藏事件/统计即升级。五级证据阶梯规范文本 → TCK 断言 → RI oracle → ≥3 生态实现 → Caffeine 内部 parity内部不一致是最高信号。parity 测试是回归防线TCK 只测终态事件流与统计量必须靠参数化 parity 测试钉死。双命令验证改一致性相关代码后:jcache:test与:jcache:tckTest必须都通过TCK 系统属性把标准javax.cache.*接口映射到本仓库的CacheProxy/CacheManagerImpl等实现类。产出结构化合并报告以 A–N 覆盖矩阵领衔每条发现带见证与方向依据子审计器必须写组后缀路径防止并行覆盖。【免费下载链接】caffeineA high performance caching library for Java项目地址: https://gitcode.com/gh_mirrors/ca/caffeine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考