com.baomidou.mybatisplus.core.handlers.MetaObjectHandler

我买了汉。预算内买贵的一般都不会错，钱这个东西花哪哪儿好

users.stream().collect(Collectors.groupingBy(User::getKey);

链路用 skywalking （ pinpoint 要能接受比较高的性能损耗），线程池和父子线程的问题用 TransmittableThreadLocal + mdc 解决了，zipkin 是侵入式方案个人不是很喜欢，trace 、metric 、log 还是非侵入式的用起来更舒服，业务也没有感知。

生产级代码就别自己写了，用 https://github.com/baomidou/dynamic-datasource-spring-boot-starter 这个好了，唯一要注意的是分布式事务的部分需要自己重写一下，如果是为了学习也可以看一下人家的代码，也是 AbstractRoutingDataSource 这个路子

@ychost dragonwell8 中的实现还是非常重的，loom 其实不是传统的协程更应该叫纤程，之前听梁希他们分享过他们实现的协程，他自己也说会比较重，主要还是因为他们最开始做的时候 loom 还不存在所以想自己做一些开创性的东西，不过到业务系统层面除非是阿里那种规模的集群其它的大差不差了

@ipwx 这种是不是比较依赖 hash 算法，不然 hash 碰撞了不就 g 了吗？拿时间换空间？

说一下他们的差别好了, 有没有意义自己见仁见智吧
1.服务器上只有一个 jvm ，code cache 什么的只有一份，内存回收的效率比较依赖 gc ，g1 和 zgc 对大内存比较友好，如果是比较老的 jvm 可能会比较拉胯，值得注意的是超过 32G 以后 jvm 的指针压缩会失效导致内存利用率下降；
2.1 个 tomcat 启动 10 个 jvm 进程，这种我认为和第三种区别不大，唯一的区别是所以应用的配置比较容易保持一致，但你本身暴露端口之类的配置还是要在启动一个实例后修改（不然会端口冲突），个人角度认为没必要；
3.这种算是目前比较主流的方式，优点就是可以滚动升级服务没有不可用时间，同时如果代码有内存泄露等问题，能够先局部重启保证服务可用再保留部分应用慢慢排查问题，很多问题的影响范围可以被缩小，它的缺点是同样的 code cache 会有重复的多份比较浪费内存，一些内存级的缓存也都会被缓存多份，还有就是一些单 jvm 没有问题的代码可能会出现一些问题（这个属于代码的问题可以避免和修复）
题外话：一般的 java web 都是 io 型项目，其实 cpu 都是利用不充分的，32c 和 64g 基本上两者的利用率是对不齐的，可以再多请求一些内存资源

因为大多数业务应用都是 io 密集型，这样可以更方便的压榨 cpu ，这么做的有 tomcat 、dubbo 、spring 、netty 等，接收请求的线程和处理线程一般都是分开的，业务代码这么做要看情况而定。

当前，因为不是所有数据都在 buffer pool 里面，一般情况下 B+树只有根节点才是常驻内存的。

这叫内存逃逸。。。看下逃逸分析相关的知识就明白是怎么回事了，内存泄露更多的是一个过程，因为回收不掉导致可用内存随着程序运行越来越少。

目前每个 class 独立一个, 但官方有意图想做到一个 jar 中所有类共享一个常量池，至于全局一个可能有些弊大于利不是很说得准。

会, 直接打入基础镜像去了, 不过容器的权限要控制一下, 核心应用的容器权限应当只有 owner 才能进，至于说问题理论上只要允许进入容器并执行命令都存在问题(就是要暴力 kill -9 你咋办)，当然容器命令可以限制如 rm -rf *、kill 等，再剩下的的就是培养开发人员的意识了

三态和两态的区别，我记得知乎上有人讨论过三进制其实更适合作为计算机的底层实现机制，只是历史已经走到这了。

真实原因是使用了事务，这要求实现单应用内的分布式事务，可以依赖 JTA 去做，比如 Atomikos 、Bitronix 都是不错的开源的 JTA 实现，我这边是实现了一个 DynamicTransactional 注解，多数据源的事务使用我这个注解，依赖注解的切面里使用 JTA(这里我用的是 seata)维护了多数据源下的分布式事务

泛型擦除会擦除到类的上界，普通的对象的上界就是 Object ，一般是拿不到的，如果 method 里有声明可以依赖 ParameterizedType 去获取，不然就取里面的对象的类型，如果还是空的那 jvm 就感知不到了，需要你手动设一个上界或者传进去

提供点思路
1.动态调用分析，依赖全链路监控系统，如 skywalking 、pinpoint ，有了这个之后你的方法被哪些服务调用甚至流量都能够计算出来
2.静态调用分析，在打包过程中对最终打包的 jar 的 class 进行静态分析（核心就是记录方法签名），这样就能够知道一个 rpc 方法被哪里所调用，缺点是代码里写了但是实际中可能已经不再使用这种情形无法分析，优点是成本较小，对上层业务 0 感知
3.全文代码检索，类似 kooder 这种全局代码检索，直接输入类的全名就能看到调用的地方，同样对上层业务 0 感知，且能覆盖全部分支，而非仅运行时的版本，缺点是如果是三方合作拿不到源码的话就比较难搞，相比之下 1 和 2 只需要一个部署的 jar 包

@wbd31 这个核心参数一般都会修改的，使之更契合自己的业务，比如阿里的 adb ，应该说官方默认的是 1s 。

refresh=wait_for 还是别加了。。，默认 1s 刷新还是能够满足伪实时诉求的，加了之后对整个 es 的负荷更多反而更加影响性能，用 canal 的话就作为一个 binlog 的采集器好了，自带的 adapter 限制和 bug 太多了。。我这边都是 canal 集群->RocketMQ 集群->多 java 应用进程->ES 集群，慢在哪一步也更好分析，目前你这样感觉要筛查下 binlog 自身的延时，还有 es 的写入频率可能要做适当的调整