这个场景反射就是最简单的方案。

1.agent + 字节码改写 这个组合几乎可以做任何事情，但引入 agent 其实是个成本很高的事情还是要慎重；
2.静态代理 对方法有入侵；
3.定义一个函数把 main 传进去；
4.字节码改写有三个时机，编译期织入、装载期织入、运行期织入，完全可以像 lombok 那样做一个编译期织入的注解，关键词 AbstractProcessor ；

所以有了 fastutil 这个库。。话说 java 自己的 Valhalla 项目正在做泛型特化以后你就可以用 List<int>了。

配置一堆层是指 mapper 、dao?
纯用 mybatis 的人不多了，现在基本上都是用 mybatis plus ，单表增删改查用 baseMapper 复杂的才会用 xml ，这玩意你就理解成是个专门存放 sql 的地方，古早时期 sql 都是混在 java 代码里面的，后来发现维护太麻烦了（比较重要的原因是当时没有多行字符串这个语法糖）就想把 sql 和代码区分开，mybatis 选取了当时流行的 xml 格式使用 ognl 作为动态能力的补充，确实解决了代码和 sql 分离这件事情，只是到了现在 xml 人人喊打，ognl 表达式也略显笨重所以质疑声此起彼伏，但叫归叫其它能取代它且稳定好用的框架暂时还没出现。
歪楼：mybatis 不是 orm ，java 的 orm 月经帖太多了，目前的几款 orm 如 mybatis plus 、jpa 、hibernate 都有各自的问题，我对此比较悲观除非有 C#那种强大的语法糖，一款非常好用且完备的 orm 在 java 里可能很难诞生了

所以说 goto 部分场景下还是有价值的。
针对这个场景用流也是个不错的方案。

无非就是顺序消息存在的必要性，答案是有必要。只是说不能一股脑地把问题都丢给中间件以为就万事大吉了，10TPS 有 10TPS 的处理方式，1kTPS 有 1kTPS 的，10wTPS 也有 10wTPS 的，就事论事选择最适合业务的。

瞄了眼源码，除非改源码实现不了。

第一 MP 功能确实不够强大，其实对于 excludeProperty 本来应该是提供 @JsonIgnore 、 @JsonIgnoreParentProperties 这样单独的注解去实现的，同时还要留给外界一些扩展点类似 jackson 的 BeanSerializerModifier 去做自定义。
第二虽然知道很多小项目怎么写都可以顺手就行，但是 DO 一把梭随便继承这种坏习惯能避免还是尽量避免，至于为啥不用继承这几乎是一种共识了，耦合度 继承 > 接口 > 组合。

都会进入内核态，只是 synchronized 的重量级锁底层是插入了 monitorenter 和 monitorexit 两个指令，以最流行的 JVM HotSpot 为例其底层使用了 mutex （ linux 下）这个非常重的锁，而对于 AQS 使用的 LockSupport 的 park 和 unpark ，其底层会使用操作系统提供的原语，如 pthread_cond_wait （对于 POSIX 线程库）或 Windows 上的 WaitForSingleObject 等来实现线程的挂起，再使用 pthread_cond_signal （对于 POSIX 线程库）或 Windows 上的 SetEvent 等来实现线程的唤醒，这些操作系统原语通常是高效的，允许线程在等待期间几乎不占用 CPU 资源，从而有效地实现了非阻塞的线程等待和唤醒。

不过 1.8 以后性能大差不差了（很多东西也互相借鉴其实逻辑上已经高度相似），只是 AQS 系列的锁更灵活 api 更好用，如果只有上锁解锁随便用哪个。

如果参数是已经计算好的变量判断不判断其实都还好，如果占位符的参数还涉及到比较吃 cpu 的计算最好还是判断下能节省点 cpu 。

mq or 定时任务

@sl450282169 正解

看看 SOFA Boot ，本质上就是自定义 classloader 这条路。

ShardingSphere-JDBC 是客户端分表，一般用分库分表基本上用它的比较多（对程序员更可见也不依赖中间件），ShardingSphere-Proxy 是代理层中间件和 dbProxy 比较类似，允许定义全局表、分片表、序列这些，但如 3 楼所说这些大概率都是些中间产物，未来真正的分布式数据库会淘汰掉它们，当然从学习和实现业务的角度来说学一学倒也无妨。
ps: 很多大数据量的表的产生来自于最早的设计问题，一般适合分库分表的都是些流水表

有没有比较便宜的推荐，自己的快到期了。

@mmdsun 真这么简单早升级完了，光 JPMS 和反射的限制就够喝一壶的，更别提原有的 java agent 可能都要失效了，我手上的项目 100 多个应用，2000 多个 pod ，要真到 21 没个两年下不来。

生产还是 java8 ，太难升了，比如你依赖的单点登录的 client 是 1.8 吧不支持 11 你怎么推动别人改造
可以看看这篇 为什么很多公司选择不升级 JDK 版本，仍然使用 JDK8 ？ - 君莫惘的回答 - 知乎
https://www.zhihu.com/question/325293339/answer/1150270157

spread 出来的都是正值，但是节点的 hash 还有其它的几个状态：
static final int MOVED = -1; // 代表当前 hash 位置的数据正在扩容！
static final int TREEBIN = -2; // 代表当前 hash 位置下挂载的是一个红黑树
static final int RESERVED = -3; // 预留当前索引位置

面试是没有固定公式的，但对于某些固定的问题确实存在着套路，最基本的 3w （ what-how-why ）原则就很好用。
比如 aop 这个命题, 什么是 aop?怎样使用 aop ？为什么需要 aop ？这些内容相对浮于表面但如果面试并不是什么大公司，面试官的水平也没有多高可能也就够用了。再向下挖掘，动态代理/静态代理 -> jdk 代理/cglib 代理 -> 字节码改写 asm/javasist -> agent -> jvmti -> jvm 源码等等，知识是有层次的，对应面试这件事情来说先选定目标公司，然后比面试公司的平均面试深度再深一个 level 一般就够用了，因为很多东西一下子是学不完的，你可以参考常见的面试题，对其中提到的知识点做些分层再做出合适的评估。

如果没有 IService 这个设计 mp 的风评还能更好点。