总结一下本篇文章的思路，我们先从DDD最基础的OOP面向对象入手，然后介绍了DDD的四层经典架构，接着阐述了DDD里面核心的领域实体和Repositoy还有领域服务这样的战术设计规范和方法，最后结合实际工作中遇到的场景来引出DDD战略设计的一些方法和思路。受制于笔者实践DDD的经验有限，虽然还有很多相关的内容本篇文章没有介绍，但是仍然想在这里抛出一个问题：什么时候？什么项目使用DDD比较合适？我相

这几天，JetBrains Fleet 可以说是闹的沸沸扬扬，官方的态度很明确，我们是下一代 IDE，使用了 IntelliJ 代码处理引擎，并且是建立在 20 年的 IDE 开发经验的基础之上。听起来口气就很大，网上也是铺天盖地吹。今天我也来体验一把，看看这玩意到底能不能干掉 VScode，毕竟微软的 VScode 在轻量级这方面就是妥妥的标杆，Fleet 到底牛不牛逼，肯定是要以 VScode

但是在极限情况下， 即便通过上面的数据校验处理， 也有可能出现99.99%数据一致， 不能保障完全一致，这个时候可以在旧库做一个readonly只读功能， 或者将流量屏蔽降级，等待日志增量同步工具完全追平后， 再进行新库的切换。日志增量同步过程随时可能会产生新的数据， 新库与旧库的数据追平也会是一个无限逼近的过程。修复切换异常数据：在切换过程中， 如果出现，Canal未同步，但已切换至新库的请求（

当然也可以支持bootstrap.yml方式来管理配置，这样就不会出现这个报错了 这里我们直接改用bootstrap.yml 把之前的application.yml全部改成bootstrap.yml，就可以成功启动服务了。也就是说，当Consul面板重新启动时，之前创建的配置数据，都会消失。这显然不是我们预期的结果。其中config/application文件夹中的配置对所有注册到consul的服

在开发过程中处理异步任务的时候，我们基本都会使用自定义的线程池，进行异步任务的处理，使用自定义的线程池处理任务的好处，无非就是降低资源消耗、提高响应速度，这里就不做过多的解释说明了，主要来探讨下，如果异步任务中出现异常，线程池是继续运行还是停下来报错呢；只有了解了线程池提交任务的步骤，以及异常的处理，才能让我们在使用线程池的时候出现异常，能够及时处理，避免线程池提交任务处理失败导致数据丢失；

采用 http 连接池的主要好处在于连接复用，减少创建/销毁 tcp 连接的开销，提高性能。一般有以下常用参数：**最大连接数：**限制连接池中的最大连接，不能配置的太小，否则高并发时容易阻塞。**单路由最大连接数：**一般用在网关中，微服务架构体系下，网关可能需要连接几十个微服务，限制单路由最大连接数，某个服务发生异常时，可以尽量不影响其他服务。**最大空闲连接数：**如果连接池中的连接都不再使

不可变对象指对象一旦被创建，状态就不能再改变。任何修改都会创建一个新的对象，如 String、Integer及其它包装类。公共静态不可变（public static final ）变量也就是我们所说的编译期常量，这里的 public 可选的。实际上这些变量在编译时会被替换掉，因为编译器知道这些变量的值，并且知道这些变量在运行时不能改变。这种方式存在的一个问题是你使用了一个内部的或第三方库中的公有编

logback, log4j2 等都是非常优秀的日志框架， 在日常使用中，我们很少会关注去使用哪一个框架， 但其实这些日志框架在性能方面存在明显的差异。尤其在生产环境中， 有时候日志的性能高低，很可能影响到机器的成本， 像一些大企业，如阿里、腾讯、字节等，一点点的性能优化，就能节省数百万的支出。再次， 统一日志框架也是大厂常有的规范化的事情， 还可以便于后续的ETL流程， 因此，我们选一个日志框架

String 和 StringBuffer、StringBuilder 的区别在于 String 声明的是不可变的对象，每次操作都会生成新的 String 对象，然后将指针指向新的 String 对象，而 StringBuffer、StringBuilder 可以在原有对象的基础上进行操作，所以在经常改变字符串内容的情况下最好不要使用 String。最明显的区别是 ArrrayList底层的数据结

本篇是关于 JVM 内存的详细分析。网上有很多关于 JVM 内存结构的分析以及图片，但是由于不是一手的资料亦或是人云亦云导致有很错误，造成了很多误解；并且，这里可能最容易混淆的是一边是 JVM Specification 的定义，一边是 Hotspot JVM 的实际实现，有时候人们一些部分说的是 JVM Specification，一部分说的是 Hotspot 实现，给人一种割裂感与误解。