不会导致新 class 产生，其实基本是依照这个 class 结合 handler 生成一个新的代理对象。至于这些对象不使用后怎么处理就看 gc 了。

现有的所有垃圾收集算法实际上并不能避免 STW ，而现在只能做到尽可能减少 STW 时间，而有些像 ZGC 这样的就是主打低延迟的垃圾收集器。而 STW 主要影响那种尾部延迟(tail latencies ，多个请求下，响应最慢的请求延迟)比较敏感的服务。ddia 中有这样描述延迟影响的一段话：
“响应时间的高百分位点（也称为 尾部延迟，即 tail latencies ）非常重要，因为它们直接影响用户的服务体验。例如亚马逊在描述内部服务的响应时间要求时是以 99.9 百分位点为准，即使它只影响一千个请求中的一个。这是因为请求响应最慢的客户往往也是数据最多的客户，也可以说是最有价值的客户 —— 因为他们掏钱了 [19] 。保证网站响应迅速对于保持客户的满意度非常重要，亚马逊观察到：响应时间增加 100 毫秒，销售量就减少 1% [20] ；而另一些报告说：慢 1 秒钟会让客户满意度指标减少 16% [21 ，22] 。”
而类似 c c++ rust 则属于没有 gc 的语言，需要开发者自己控制内存释放，所以微观来说回收内存会导致指令级的停顿，但是因为开发者有着对对象清晰的结构梳理，在使用得当的情况下则不会导致类似 GC 这样相对来说集中且漫长的延迟（除非你自己整了一套 gc 机制）。

@THESDZ 学习到了，非常感谢

@dqzcwxb 是的，这就是我所不满意 Spring Cache 所作的：“将命名空间下所有缓存删除”；这篇文章中“针对一个表的某些操作不在他独立的 namespace 下进行。”这句话也就是之前所说外键之间的无奈，所以我仍然认为 service 中进行外键数据填充操作是最佳实践。
不过言归正传，Kache 因为缓存实体是分离的，对于条件方法之间的缓存是以索引的形式再次指向实体的结构，因此当实体更新时不会像 spring cache 将缓存全盘删除，而是仅仅将多个条件方法的“索引缓存”（类似一个 list<指针>）删除掉，相较于 spring cache 来说可以避免缓存的重复序列化而可以再删除后写入缓存时只需要存入索引缓存即可，避免数据序列化和冗余。并且因为获取缓存脚本与本身缓存结构，缓存删除与读取是无锁并行的。

@233373 最近了解的一个嵌入式开源社区貌似有把前后端代码开源：
前端： https://github.com/rymcu/nebula
后端： https://github.com/rymcu/forest
社区网站： https://rymcu.com/

@dqzcwxb 在过期时间上的处理话，在存入缓存时会先向 redis 中去重，得到缺少的数据再存入，而重复的 id 则会延长存活时间。而刷新策略目前属于较为悲观的该类型所有索引缓存全删，不过相对于 spring cache 的缓存删除成本来说小很多。目前的数据冗余判断依据是依照数据库中主键的概念，做不到非常深层次的数据重用。

@fzdwx 因为看到了你的浏览记录，感觉 websocket spring boot starter 很不错，所以 star 了一下

@fpure 项目驱动学习，原型只是一个 AOP ，再逐渐变成 spring starter 再分离变成 Proxy 与 spring starter

@dqzcwxb 本身定位的话仍然是主要面向数据库 IO 的，而您说的问题大多是牵扯到外键，本身这个框架是可以与 Spring Cahe 结合，可以做到 Spring Cache 负责 Service 层用于外键的 Bean 装填处理，而 Kache 应当做好的是对数据库的一层旁路，用于最大化避免数据重新走入数据库之中，目前 Kache 对于数据的感应都是通过应用的，也是兼容分布式的，但是如果是外置工具操作数据库的话确实可能会导致数据变化而 Kache 无法感知，后继有使用 binlog 等手段的可能。
简而概之就是尽可能不要要外键填充的操作放入的持久化操作之中，否则持久化的方法难以复用并且会导致数据千变万化，Kache 本身注解有个 involve 属性用于干涉其他 Bean 类型缓存的清除，但尚未有完美解决这个问题的方案