Aresxue

目前每个 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 的写入频率可能要做适当的调整

要看预估数据量喽，第一种 in 在 name 超大的情况下会造成 sql 语句超过 max_allowed_packet, 而且不利于做缓存优化，还有可能因为单次数据量过大撑爆，第二种就是单次连接只查一条数据过于浪费，可以折中一下， 分析下 name 的 Cardinality, 然后一批 name 过来将其拆分为几个小集合，单个集合按照 cardinality 的预估最终维持查出的数据量单次在指定大小(如 1000)左右，然后在内存里拼接数据, select 语句的开销除了 query 还有 fetch 和 transport, 多线程去做一批的查询最后汇总一般比大结果集单次查询会快上一些。最后说一句如果不是 p0 级接口且有性能诉求不要进行上述优化。。。