泛型擦除会擦除到类的上界，普通的对象的上界就是 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 级接口且有性能诉求不要进行上述优化。。。

全升级了吧，最偷懒也是最省事的方法，反正版本号也不会用完。想严谨点各个模块独立版本号一定要把子版本号放在一起管理，不然子模块一多就是场灾难，deploy 正式版时也有可能会造成一定的困扰

正常水位 500tps，峰值 1500 左右，压测 1w+

单一系统的，接口监控系统（线上线下）和全链路请求追踪系统其实都已经有了，现在是想做业务回归，因为项目在重构且变化比较快。十分感谢您的耐心

正在用你敢信

@HappyFox 我觉得这是最合理的，但是不够健壮，如果是较靠前的业务接口出问题了，后续接口都没法玩了

老月经贴了，继承->接口实现->容器->注解，当你能清晰弄清楚它们的依赖程度并能在项目中选择合适的时候你就不会有困惑了。当然这是对于需要精细打磨的项目而言，而大多数的项目本身就是对业务，本身就是一种快消品罢了

因为现实中流量是极其不均匀的，消息队列不是为了技术出现的，是为业务出现的

@retanoj 那就纯粹需求描述，现在代码里有很多 BeanUtils.copyproperties （或其他的）属性 copy 操作，但对于这种 copy 点击 idea 中的 field，是无法展示该字段的 usages 的，在查看代码时变量的修改就非常难以追踪，现在我想完成一个插件点击 field 就展示 BeanUtils.copyproperties 的地方，之前的实现思路是按照 java 反射那套思路来的（获取 field 所在 Class，找到该 class 的对象， 当这个对象被 BeanUtils.copyproperties 时，假设是 source，就获取 target 的 class，在那个 class 中按照 field 的 name 和 type 寻找，找到了就说明匹配上了，这个 BeanUtils.copyproperties 就被展现出来）

问题的原因就是你把 DO 和 DTO 变成一个了，这种做法本身是有点问题，但非要这么做也没事，client 包依赖 JPA 然后 JPA 的依赖变成 provided，实际 run 的应用中也有要 JPA 的依赖，两个依赖版本要尽量保持一致

@different 差不多是这样子。。。但是阿里的内网只听说道哥进去过。

这个主要是为了应付安全扫描，避免数据库用户密码明文裸奔，实际上用加密串半分钟就能解出来用户密码，设置这么简单是因为这种场景下加密太复杂反而会影响启动速度，真正保护数据库其实还是靠的网络层内网隔离

一般无非就还是插件, idea 官方能出个功能是最好的，虽然构造器更好但如果没有其他配合还是用 field 注入吧，至少不用在新加服务后还要改构造器

@majiaxin110 呵呵，lombok 你还能和项目管理扯上关系，先把燃尽图、版本管理、commit 规范弄清楚再来说项目管理和团队管理，我名义上手下的人可能比你整个部门都多。关于插件，且不论我是不是升级，一个加进来还需要考虑 ide 兼容性的插件你也敢向向里面加，合着不兼容就让剩下所有人回退版本？

@majiaxin110 呵呵，就是你这种人，我特么因为你用了 lombok 合着我 idea 还要回退到老版本？顺便睁大你的眼睛看看这个 issue 是什么时候的，是说的哪个版本