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

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

稍微大点的公司都是有基建的，很多都是基于 jdk8 的中间件去做二次封装和二次开发的，你让基建一下子全部适配高版本 jdk 几乎是一个不可能的事实，除非你要做一个独立性很强且足够简单的应用可以不依赖各种中间件和原有的登录、权限、账号体系，这样才算是真正的没有历史包袱的，否则上述每一个地方都会是拦路虎，到最后你可能会发现降级到 jdk8 是最佳方案。

依赖 devops 去做吧，加一个依赖检测环节，本质上基于 maven-enforcer-plugin 去做各种依赖校验就好，不通过就不给发布

简单点就 proguard ，复杂那可真就太复杂了

com.baomidou.mybatisplus.core.handlers.MetaObjectHandler

我买了汉。预算内买贵的一般都不会错，钱这个东西花哪哪儿好

users.stream().collect(Collectors.groupingBy(User::getKey);

链路用 skywalking （ pinpoint 要能接受比较高的性能损耗），线程池和父子线程的问题用 TransmittableThreadLocal + mdc 解决了，zipkin 是侵入式方案个人不是很喜欢，trace 、metric 、log 还是非侵入式的用起来更舒服，业务也没有感知。

生产级代码就别自己写了，用 https://github.com/baomidou/dynamic-datasource-spring-boot-starter 这个好了，唯一要注意的是分布式事务的部分需要自己重写一下，如果是为了学习也可以看一下人家的代码，也是 AbstractRoutingDataSource 这个路子

@ychost dragonwell8 中的实现还是非常重的，loom 其实不是传统的协程更应该叫纤程，之前听梁希他们分享过他们实现的协程，他自己也说会比较重，主要还是因为他们最开始做的时候 loom 还不存在所以想自己做一些开创性的东西，不过到业务系统层面除非是阿里那种规模的集群其它的大差不差了

@ipwx 这种是不是比较依赖 hash 算法，不然 hash 碰撞了不就 g 了吗？拿时间换空间？

说一下他们的差别好了, 有没有意义自己见仁见智吧
1.服务器上只有一个 jvm ，code cache 什么的只有一份，内存回收的效率比较依赖 gc ，g1 和 zgc 对大内存比较友好，如果是比较老的 jvm 可能会比较拉胯，值得注意的是超过 32G 以后 jvm 的指针压缩会失效导致内存利用率下降；
2.1 个 tomcat 启动 10 个 jvm 进程，这种我认为和第三种区别不大，唯一的区别是所以应用的配置比较容易保持一致，但你本身暴露端口之类的配置还是要在启动一个实例后修改（不然会端口冲突），个人角度认为没必要；
3.这种算是目前比较主流的方式，优点就是可以滚动升级服务没有不可用时间，同时如果代码有内存泄露等问题，能够先局部重启保证服务可用再保留部分应用慢慢排查问题，很多问题的影响范围可以被缩小，它的缺点是同样的 code cache 会有重复的多份比较浪费内存，一些内存级的缓存也都会被缓存多份，还有就是一些单 jvm 没有问题的代码可能会出现一些问题（这个属于代码的问题可以避免和修复）
题外话：一般的 java web 都是 io 型项目，其实 cpu 都是利用不充分的，32c 和 64g 基本上两者的利用率是对不齐的，可以再多请求一些内存资源

因为大多数业务应用都是 io 密集型，这样可以更方便的压榨 cpu ，这么做的有 tomcat 、dubbo 、spring 、netty 等，接收请求的线程和处理线程一般都是分开的，业务代码这么做要看情况而定。

当前，因为不是所有数据都在 buffer pool 里面，一般情况下 B+树只有根节点才是常驻内存的。

这叫内存逃逸。。。看下逃逸分析相关的知识就明白是怎么回事了，内存泄露更多的是一个过程，因为回收不掉导致可用内存随着程序运行越来越少。

目前每个 class 独立一个, 但官方有意图想做到一个 jar 中所有类共享一个常量池，至于全局一个可能有些弊大于利不是很说得准。

会, 直接打入基础镜像去了, 不过容器的权限要控制一下, 核心应用的容器权限应当只有 owner 才能进，至于说问题理论上只要允许进入容器并执行命令都存在问题(就是要暴力 kill -9 你咋办)，当然容器命令可以限制如 rm -rf *、kill 等，再剩下的的就是培养开发人员的意识了

三态和两态的区别，我记得知乎上有人讨论过三进制其实更适合作为计算机的底层实现机制，只是历史已经走到这了。