如果有网络分区partition (P)，系统就必须在可用性availability和一致性consistency (A and C)之间取得平衡; 否则else (E) 当系统运行在无分区情况下,系统需要在 延迟latency (L) 和 consistency (C)之间取得平衡。
PACELC定理是CAP定理的扩展。
MongoDB（默认配置）下是PA/EC系统，mongo读写都在主节点上，它只需在主节点上写入成功就返回（不像raft需要多数复制成功），当主节点和备节点分区时，可能会丢失数据，所以说PA，在无分区的情况下，由于读写都在主节点，肯定能读到最新写入的数据，所以是EC。另外Mongo可以配置为写入大多数节点读主节点，这样就是PC/EC系统了。
生产环境的JVM进程经常被运维报告有OOM的情况，运维的描述是，内存一直在缓慢增长，1-2天就会出现OOM的情况。因为已经严重影响到客户的使用，所以采取由运维定时监控，与客户交流，开发负责排查问题的策略。
由于开发是没权限进入生产环境的，要高效率解决问题，必须能在测试环境复现。查看生产环境的日志，确认容器出发OOM的接口，然后使用Jmeter在测试环境压测该接口，发生OOM的情况，问题能够复现。
在测试环境建一个和生产环境规格一样的容器，使用Jmeter压测，确认问题能复现。
无锁编程里最复杂，最难理解的莫过于是内存顺序。
程序不一定会按照源代码的顺序执行，这称之为乱序。乱序的必须遵循的原则是：在单线程执行下，乱序与不乱序执行的结果必须相同。所以，在单线程的环境里不需要注意乱序的问题，而到了多线程环境就需要考虑乱序。
乱序产生的原因有好几种：
无锁编程是一项挑战，不仅因为任务本身的复杂性，还因为要深入理解这个主题是非常困难的。
我第一次接触无锁（lock-free，又称为lockless）编程是Bruce Dawson优秀而全面的白皮书《Lockless Programming Considerations》。和很多人一样，我也有机会将Bruce的建议付诸实践，在Xbox 360等平台上开发和调试无锁代码。
在微服务系统中，往往需要一些手段来应对流量激增的情况。例如，弹性伸缩，在高流量时自动扩容。但弹性伸缩往往只能在无状态服务上比较容易实现，在有状态的服务，例如数据库、消息中间件、分布式缓存上，是比较难实现的。这时就需要流量控制，只接受系统能处理的流量，拒绝或排队处理不过来的流量，从而保护微服务系统的可用性。
服务在自己处理不过来时，应该拒绝其它服务的请求，保护自己，这就是限流降级。当服务发现它调用一个服务，在发现这个服务“不行”时，应该不再去请求它，从而保护这个服务，但其实也是在保护自己，因为服务“不行”时，往往响应很慢，拒绝请求它避免大量请求在自己服务内堆积，这就是熔断降级。一般而言，限流侧重于流量控制，预防系统被压垮，一般通过拒绝或者排队等流量整形手段应付暂时不能处理的流量。而熔断侧重于在发现依赖的服务“不行”时，如：每秒请求异常数超过多少，每秒请求错误率超过多少时，每秒平均耗时超过多少时，在一个时间窗口内拒绝请求该服务，在一个时间窗口之后再恢复请求，从而保护依赖的服务。当然，服务也可以自己统计自己的错误率，平均耗时等，从而熔断其它服务的调用。
在编写单元测试时，不应该依赖任何外部依赖，不依赖与该测试无关的代码。在Spring应用中时，单元测试不应该依赖Spring，因为Spring启动需要把所有的bean注册到Spring容器中，与该测试无关的bean启动失败会导致测试失败。另外，我们还需要把Spring的各项配置正确才能启动单元测试。所以，单元测试应尽量不依赖Spring。对于外部依赖，例如数据库、RPC调用、HTTP调用等等，我们需要mock这部分实现，来保证单元测试的可重复执行性。
虚拟线程是轻量级线程，可以减少编写、维护和调试高吞吐量并发应用程序的工作量。虚拟线程在JDK 19中作为预览特性引入，在JDK 21中作为正式特性引入。
在其它语言中也有类似于虚拟线程的技术，例如Go中的goroutine。
关于虚拟线程的背景信息可以参考：JEP 444。
线程是最小的可调度单元，多个线程可以并发运行，在很大程度上，它们之间是独立运行的。 线程是java.lang.Thread的一个实例。线程分为两种类型：平台线程（platform thread）和虚拟线程（virtual thread）。
