永久代可以理解为 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 不支持动态编译函数所以没法抄作业。

类不会重载，只是会被 retransform ，简而言之就是方法体里面的字节码会被替换掉，JVMTI 提供了这样的机制，一般都是各种 agent 在启动时就会修改指定方法的字节码，不过也有些剑走偏锋直接在框架中用 asm 或者 javasist 修改的，像 HikariCP 就使用了各种字节码的黑魔法，可以看下有没有使用这两个框架的 api 的地方

当然可以用 class 只是 interface 的耦合更低，一般优先推荐 interface ，内部服务能确定不需要给别的服务复用的注入 class 也没啥问题。

flink 没玩过，但是 canal 绝对是个坑，一个是 cpu 老是莫名其妙跑满，还有对主从模式很多地方都没有支持非常坑。

写一个 XxxBeanSerializerModifier 继承 com.fasterxml.jackson.databind.ser.BeanSerializerModifier 获取注解做修改

修改 spring mvc 序列化的 objectMapper 对象，objectMapper.setSerializerFactory(objectMapper.getSerializerFactory()
.withSerializerModifier(new XxxBeanSerializerModifier()));

因为这样信息更全面，不考虑 open tracing 的标准，仅从开发人员角度出发，如果业务代码中循环调用同一个 dubbo 服务不在消费端开一个 span 你很难一眼看清是第几次 consumer 出了问题其当前的调用对应的 provider 又是哪一个。从系统调用的层面看 http 入口是主调用，database 、mq 、cache 、rpc consumer 这些是子调用，而对于下游应用来说 rpc provider 则是入口，即满足 A 的子调用是 B 的主调用的链路逻辑，每个应用既是应用自闭环的同时还是全链路的一部分，举个比较极端的例子，A 是本业务域系统使用了 SkyWalking ，它消费的服务归属于另外业务域的系统 B 是没有 SkyWalking 的 agent 当然更不会上报链路信息，此时如果没有 DUBBO Consumer 没有新开一个 Span 将如何标识这一次 dubbo 调用呢？

数据库里不要用 not null 设个 default ''好了

一个是历史原因，dubbo 开始的时间挺早的，那个时候 AsynchronousServerSocketChannel 可能刚出现甚至没出现，第二个是 java 里面并没有真正的 aio ，很多时候 aio 的实践效果反而没有 nio 性能更好。

动态装载的类也是有它的开发环境和过程的，可以考虑在开发过程中把这个类使用的类打包为一个新的 jar ，装载时使用自定义的 classloader 去 load 这个 jar ，至于实际实现的话可以用静态分析（ import 的递归和对反射的分析）和动态分析（限定类的指定运行方法，开发时自己 run 一遍将 jvm 中所有类都记下来，将 jdk 和已有依赖的类排除其它的类合并为一个新的 jar ），这东西简单想想还行实际做起来确实挺复杂

指定编码格式为单字节编码，如"ISO-8859-1"

@idblife 是在发布流程里面利用 maven-enforcer-plugin 做检测，不是让应用工程引入，如
mvn org.apache.maven.plugins:maven-enforcer-plugin:3.0.1:enforce ，在发布流程中执行该插件，不满足规则则不允许发布，有 jenkins 在 jenkins 的节点里面新增一个依赖检测的节点就好