LearningGp

低频访问的话，是不是采用较短的熔断时长即可

麻烦提供下增加 CAS 锁前后的 JMH 性能测试报告，我们这边也同步做下测试 另外，如果性能存在一定差异，建议增加一个开关来控制是否使用这种严格模式

Due to this PR's inactivity and the unsigned CLA, we are temporarily closing it. Feel free to create a new PR if you still intend to contribute after addressing the...

建议参考[在生产环境中使用 Sentinel](https://github.com/alibaba/Sentinel/wiki/%E5%9C%A8%E7%94%9F%E4%BA%A7%E7%8E%AF%E5%A2%83%E4%B8%AD%E4%BD%BF%E7%94%A8-Sentinel)来集成，指标部分可以通过采集本地的metrics日志来构建

我理解这边主要讨论了 chainMap 使用 HashMap 还是 ConcurrentHashMap 的问题。首先我们明确下使用的场景，chainMap 的使用场景主要分成两个阶段，一个是初始化阶段，一个是运行阶段。在初始化阶段中，相较于性能，我们会更关注准确性，包括对于数量的控制等；在运行阶段，则更关注性能。 回到这个问题，我用 Benchmark 跑了一下性能测试，在较高强度下，只考虑 get 操作，HashMap 相较于 ConcurrentHashMap 还是表现出了一定的优势。考虑到前面提到的使用场景，虽然初始化阶段的性能表现会略差于 ConcurrentHashMap，当前可能还是保持使用 HashMap 以获取更高运行阶段的性能更合适。 在确定了这个结论后，再看下关于更新 map 的方式，由于使用的是 HashMap，并发的读写操作存在风险，所以采用了现在这种方式。 个人的一些想法，欢迎继续讨论。

lookProcessChain 方法中的第一个 get 操作不在 synchronized 的范围内哈，还是会存在并发 get 和 put 的情况

> > lookProcessChain 方法中的第一个 get 操作不在 synchronized 的范围内哈，还是会存在并发 get 和 put 的情况 > > 是的，第一个get操作不在synchronized范围内，但是他做了一层double check。后面synchronized代码块中没有必要对chainMap进行copyOnWrite的操作。 有道理，即便有 resize 导致的脏读也是读到 null ，在有 double check 的情况下后面的 copyOnWrite 操作确实没有必要

The broader applicability of this issue remains under discussion, so we will temporarily close the PR for now.

This code is currently processing an index file. I'm having trouble mapping the issue description to the observed behavior - could you please elaborate on the exact conditions/reproduction steps you're...

> As a mature open source project, PR should be handled in a timely manner, rather than being shelved year after year. I am not sure whether this project is...