@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 一般就够用了，因为很多东西一下子是学不完的，你可以参考常见的面试题，对其中提到的知识点做些分层再做出合适的评估。

try catch 确实会会增加一些开销，主要是在 java.lang.Throwable#fillInStackTrace()中会去爬取堆栈，但参数校验这个场景下不用纠结—抛异常是综合起来性价比最高的方式，jdk 其实有 java.lang.Throwable#Throwable(java.lang.String, java.lang.Throwable, boolean, boolean)这样一个构造器去构造不需要爬栈的异常（部分场景下只依赖异常类型而不关心堆栈），但不知道为什么并没有开放出来，后续如果能开放出来搭配这个场景应该是最优解。

永久代可以理解为 HotSpot 虚拟机对虚拟机规范中方法区的一种实现方式，在物理上两者是相等的

常量 方法区

静态变量 方法区

局部变量 栈

成员变量 堆

常量且字面量 常量池

常量且引用对象 堆

静态变量且引用对象 方法区

静态变量且字面量 常量池

局部变量且引用对象 堆

局部变量且基本类型字面量 栈

局部变量且"" 常量池

成员变量且引用对象 堆

成员变量且基本类型字面量 堆

成员变量且"" 常量池

1.7 符号引用(Symbols)转移到了 native heap ；字面量(interned strings)转移到了 java heap ；类的静态变量(class statics)转移到了 java heap ，运行时常量池也到了 java heap(1.8 又到了元空间)

1.8 里面只有元空间没有持久代了

1.改下算法把 workId 放到 id 尾部（不依赖外部服务和中间件）；
2.使用 redis 自增序列（大多数项目已经引入 redis ，只有代码改造成本）；
3.号段 使用序列表按照 size 取号段到内存（更稳健的模式但改造成本大，且只有趋势递增失去了单调递增性）；
4.引入新服务（对原有服务耦合小，新增永远比修改更安全，但维护成本拉满）；
5.使用数据库代理层中间件（如果已经有了算是性价比最高的方案，不然就没有操作意义）；

顺便一提如果集群大了时钟同步是个麻烦的事情，基本上总是会有时钟回拨，对雪花算法有一定的影响，但本身也有一定措施缓解这个情况，如使用缓存的 id 等，还是要早做考虑。

自己做个开源项目是个不错的选择，说实话很多领域深入一些的话还是有很多可以做的东西的

synchronized 和 ThreadLocal 不解决没法推广到业务，尤其是 ThreadLocal 的隐患太大了，希望能快点搞定吧

目前开源产品里面没有很好用的分布式调度，看过 xxl job 和 schedulerx2 的源码，一言难尽，这个看上去也不是很靠谱的样子。说到底调度本身确实是个很复杂的东西，时区、调度策略、注册信息维护、调度发起、调度日志存储细化都有很多要考虑的点。

应用和数据库中间件是独立的，部署的时候也是分开的，你这个就是打包在一起了，拆开就好了

看 debug 做了什么，一般来说 trace 和 stack 是相对安全一些，watch 的话要小心一些如果 watct 的出入参很大会对系统造成一定的压力，建议书写表达式只获取自己关心的值而不是所以出入参，尤其是一些调用量很大的函数，建议使用-n 把 watch 次数限制的比较小，比较极端的情况下是会造成程序的卡死的，但一般情况下是不会的，自己根据业务核心程度和业务量判断一下，还有提醒各位小伙伴操作完以后记得 stop 啊，我发现 90%的小伙伴都没有 stop 的习惯。

5w 一平基本能拿下，去年真的有好多大怨种 7w 接盘。。。有人才票全杭州都看看真没必要死磕在未科，以后工作谁就能一定在家附近呢。

mybatis plus 做二开，java 对于 sql 这块目前没看到很好的管理方式，orm 框架在中型系统里面就开始捉襟见肘了，真的使用下来说实话用 xml 维护 sql 竟然还是目前综合性最好的方式（ xml 的描述能力真的很强大），只是说 xml 在可读性上真的不好，针对这一点可以自己用别的协议重写这一部分，但 mybatis 本身也足够简洁了建议换个皮就行了，从 XXX.xml 换成 XXX.sql 把原先 xml 中的信息冗余消灭一下，但 xml 中绝大多数内容还是 sql 本身所以可优化的空间也很有限。sql 目前在编程语言里最好的实践感觉是 linq ，但 jvm 不支持动态编译函数所以没法抄作业。