nathan.z

> 我也碰到这个问题了, 时间越长, 堆积的越厉害 java.util.concurrent.atomic.LongAdder内存占比高达70% 这个问题其实挺严重的，官方没有很重视，内存占用大的话根本无法上生产

> https://github.com/alibaba/Sentinel/pull/2802 MetricNode 对象的占用有缓解。LongAddr 可以从业务角度出发，减少统计。

看下你写的切面吧，进入上下文的方法，要加入origin。 ContextUtil.enter(contextName, origin); 上游要带上Header，key是S-user，不是origin

> syncLocal只作用于两级缓存（BOTH），默认不开，既然开了，所有的更新操作（包括put）当然要对所有其它JVM中的local cache执行invalidate操作。由于redis中有数据，所以其它JVM不会执行load，而是访问了redis，用redis中的数据更新local cache。 如果@Cached 查询未命中，同样会走到PUT方法，此时也会发布Redis广播？

> > > syncLocal只作用于两级缓存（BOTH），默认不开，既然开了，所有的更新操作（包括put）当然要对所有其它JVM中的local cache执行invalidate操作。由于redis中有数据，所以其它JVM不会执行load，而是访问了redis，用redis中的数据更新local cache。 > > > > > > 如果[@cached](https://github.com/cached) 查询未命中，同样会走到PUT方法，此时也会发布Redis广播？ > > 会的，但是未命中不是只发生一次么？后续就都命中了 但是这里有个点不符合逻辑，一个实例的缓存未命中，不代表其它实例的本地缓存需要驱逐。更符合逻辑的做法，应该是在@CacheUpdate或@CacheInvidate时才去广播。这个广播机制严重降低这个功能的可用性，是否有优化方案？

> > ## 背景 > > 1.1.8-beta版本下 > > ## 问题描述 > > 在使用ScheduledDtpExecutor时，指定了taskWrapperNames: [ "custom" ]。无论执行ScheduledDtpExecutor的哪个方法都不会执行指定的TaskWrapper。 经过Debug发现，调用路径ScheduledDtpExecutor#execute(Runnable command) --> ScheduledDtpExecutor#schedule(Runnable command, long delay, TimeUnit unit) --> ScheduledThreadPoolExecutor#schedule(Runnable command, long...