很有趣的问题， 看了下源码 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

生产远程 debug 模式又不能开, 出了问题当然主要就是靠日志。 但日志要做好解耦, 不然是一件十分消耗性能的事情。另外日志的输出是交错的, 有时候可能会比较难以区分，因此在日志之外 JVM 的监控工具也应该有效利用上, 比如 pinpoint 和 arthas

可以在原有基础上修改文件内容, 但直接删除或添加文件可能会导致意外的情况发生，因为打包的时候文件的结构信息也会被 maven 固定

elasticsearch 就是这么做的。。。主键的作用是作为数据库组织数据用的，以 mysql 为例默认的 innodb 使用聚簇索引, 决定了数据的位置, 辅助索引也都会带上主键信息, 所以选择随着时间递增且占用空间较小的主键比较符合时间局部性原理，能够充分利用磁盘预读

担心机器性能利用不充分就上虚拟化比如 docker, 就不用过度关注于资源调度的问题了

所以要学好操作系统、软件工程、数据结构和算法、网络通信。万变不离其宗, 高层次的抽象能让你的知识更加有体系而不是迷失在知识的海洋里。比如计算、传输、存储不可能三角，CAP 理论，TCP/IP 协议

6 楼正解, 只建立一个(username,type)的联合索引即可

老版本的 dubbo 了吧。 日志给的不全，看上去就像是正常回调。 可能是用了异步调用或者 dubbo monitor

binlog 的复制方式有两种, 按语句和按行复制, 按语句在幻读发生的情况下就会产生问题，使用严格的行复制就不会有这种问题了

不一定是 maven 的问题，也有可能是 idea 的问题，把 idea 工程的依赖全部删除, 然后重新拉取。再不行再考虑 maven 的问题, 用 mvn dependency tree > tree.txt 分析下依赖, 看是否有 jar 包对它有间接依赖， 有的话就排除掉

不想转 maven。。。2020 年了朋友，依赖管理都不用你这个项目是不打算长期活下去？
谈谈思路，仿照 maven 进行 java 文件结构的管理，把 tomcat(或其它容器)的 jar 包加到你项目的依赖里，然后自己写个启动类，里面的内容就是仿照 Spring boot 先启动 tomcat 容器,把你的源码编译成 class 放到指定的目录，再从指定目录读取这些字节码装载到 JVM 的类加载器里面去(tomcat 有独立的类加载器架构, 违反了双亲委派原则), 一些需要监听和注册服务也注册和监听到 Spring 和 tomcat 里面去

默认在 class 中，一直都是 16(常量)，你 new 的时候只是建立了引用，put 的时候才会真正分配内存空间