没听说过静态表动态表这个说法，官方没有这个概念，估计是"以讹传讹"了。官方只有行格式 Row Formats 的概念 https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format.html 默认情况下就是 DYNAMIC 。顺便说一句，mysql 要用就别用 5.7 以前的了，之前版本的性能和特性。嗯，你懂得。

题主可能是想通过无锁化来基于 HashMap 创造一种新的更高性能的并发容器，但我觉得难点其实在于 hash 冲突的问题，一个 hash 碰撞率极低的算法它的实现是极为繁琐的，哪怕你实现了它的性能必然也是很低下的，所以很多人才没有朝这个方向发展，就像都知道 RSA 的安全性更高，实际代码中加密却还大多数是 MD5

把十进制转成二进制就看出规律了, 0100，相当于取第三位, 这个做法比较老但还算常见, linux 的常用权限 755, java 里面对于修饰符的判断都有用到

gc 占用的 cpu 已经很少了，不知道你怎么先入为主得出这个结论的。顺便吐槽下 gc 日志不给，只给个线程的快照有什么用

条件允许直接上 arthas，把你整个函数切成片分析

jstack 看线程，打印什么的不靠谱，不一定是业务线程。我这就遇到过很多其他处理阻塞主程的操作, 比如日志输出（输出流重定向到 kafka ）因为用的第三方库不够健壮一步发送 kafka 消息阻塞了业务线程。

更省内存呗。。。用 jol 打印下内存布局就知道，以前 Java 主要考虑易用性，现在开始优化语法糖和内存了，变成更好的语言吧

和 Spring Cloud 以及 docker 都没啥直接关系，简单来说就是把原本要写到日志文件的输出流重定向到 elk 那边，至于是通过 filebeat 还是直接写 kafka 实现都是可以的。至于你说的 index，同一个服务用一个 index 比较好, 我这边日志量大点(一天 200G 左右)，所以是每一天一个 index(同一个服务是一样的), 最后对于日志量的问题踩了不少坑, 比如最终展示的日志是在 es 的，所以其它中间的日志保留时间可以很短, 另外像一些心跳监测的日志也可以直接做一下过滤, 还有 es 支持数据生命周期管理，比如三天内设为 hot 数据, 七天就是 warm 数据, 超过半个月就是 cold, 一个月的直接 delete(具体视业务特性而定)

不超过十个 spring 自己够用, 超过十个上个配置中心好了， 比如 nacos

不涉及修改就不会有问题。。。

Invalidate Caches 试一下, 不行就把.iml 和.idea 删了重新导入

很有趣的问题， 看了下源码 byte b 在处理时被装箱成了 Byte，有趣的是 new Byte(1)和 new Integer(1)的 hashCode 是一样的, 这很容易让人困惑, 但在 HashMap 569 行(k = first.key) == key || (key != null && key.equals(k))) 中对 key 除了 hashCode 的判断还有对类型的判断(见 Integer equals 方法 974 行)。同理你使用 map.get(new Integer(1)) 就可以取出对应的值来, 哪怕不是同一个对象也依旧可以取出你想要的值, 因为 new Integer(1) equals new Integer(1)

集群熔断降级重启定时扫描

CompletableFuture 是最佳方案，dubbo 自己的异步调用就支持。话说 IO 多才更适合使用 CompletableFuture, 能让 CPU 更充分利用,谁说不利于高 IO 的？我能想到的只是高 IO 对系统危害比较大, 以及失败及异常处理较为复杂。

处理 json 从来都不是瓶颈，至于说比性能，要看谁比, 比 C++肯定不信, 但一些静态语言应该还是比得过的。
所以要想快用 C++写好, 然后通过 JNI 调用

1.因为 CPU 有缓存, 工作内存能有效利用缓存比主存执行速度要快；
2.当分配内存的区域(Eden 和老年代都有可能)满了的时候会去 GC, 正常情况下不满就不会 GC ；
3.避免方法区溢出，元空间存放在本地内存而非 JVM 内存内，严格意义上本地内存耗尽前不会溢出；
4.只是调用不考虑初始化的话就是根据协议选取 Invoker 默认是 DubboInvoker, 拼接参数组别版本号之类, 判断是否配置了异步， 没有的话就是把异步转同步(实现上 dubbo 底层只有异步), 然后就是利用 netty 进行消息的发送和接收，实现类 HeaderExchangeChannel，中间还有个序列化操作, 默认用 hession(一种基于 tcp 的二进制协议)

Oracle 切成 mysql, 数据迁移是一方面, 业务中有复杂 sql 根本撑不起性能, 单独的数据库里基本没有几个能撑起的, 包括 Postgresql 。人家去 O 都是用的基于 mysql 或者 Postgresql 定制的分布式数据库, 想用 mysql 建议直接去买现成的基于 mysql 的分布式产品, 比如阿里的 DRDS

optional.ifPresent(修改 B), 但就像上面说的你这个简单调用还不涉及 npe 没必要使用

CDN -> DNS -> 硬件负载如 F5 > 软件负载如 nginx 和 lvs -> 应用负载如 dubbo 的请求分发(默认随机)和 SpringCloud 的 Ribbon