yty2012g

@Goooooos #15 没有 DDL 的项目当然可以。有 DDL 的项目当然还是从稳健出发，假如真有解决不了的问题，是不是能够快速的回退到团队熟悉的技术栈上。

分开搞。
第一步，先升级 jdk 17 + SpringBoot 2.x ，这一步可能遇到的就是 jdk 升级的一些问题，最好不要升级语言特性，没意义，如果可能，SpringBoot 升级到 2.7.x ，可以最大减轻后续升级的负担
第二步，升级 SpringBoot 3.x ，这一步遇到的问题更多的是 SpringBoot 的不兼容升级，从 2.7.x 升级上来阻力可以说是最低
第三步，升级 SpringBoot 3.2+ + JDK 21 ， 开启 Virtual Thread ，充分享受性能红利。
我个人的建议是：放弃语法特性升级，关注 JVM 升级即可，这样可以给自己留下最大的退路

洗烘套装：我选的东芝的 T25
电视机：准备买 TCL Q10K PRO 75 的，之前是纠结了半天 E8N Ultra 还是 Q10K pro ，最终选了 tcl 的
冰箱：准备买东芝的 548 法式
燃气热水器：准备买海尔的 TL7
空调：可能考虑华凌神机 He1 pro

使用了 Servlet 容器比较难直接操作关闭底层的连接。个人认为最简单的方法是写个 filter ，符合条件的直接 return 或者是 respose.getOutputStream().close()，但是这种依然会返回一个 200 ，只不过 content-length=0 。如果要是基于 Netty 的 WebServer ，到是可以直接 close connection ，那就彻底没有其他额外的返回了

@byte10 昨天我也是突然开窍，我就想，ng 也是监听一个端口，但是能利用好多核，这个是什么原理。原来是使用了 SO_REUSEPORT 这个 TCP 选项。然后我就和 GPT 沟通了一番，原来 vertx 也可以开启！开启后，就是通过内核做负载均衡，然后我就把线程模型改回 EVENT_LOOP ，然后多个线程监听一个端口，果然性能起飞了，终于可以利用多核了，之前压测死活 CPU 利用率上不去

@qweruiop 可能是我对 vert.x 这个框架的理解不太到位。我是压测验证了下，按吞吐量从高到低，线程模型分别是 Virtual_Thread > Worker > Event_Loop

今天下载了 Orcale OpenJDK 23 ，压测了一下。G1 GC 的吞吐量还是比 ZGC 强不少，倒是 Vert.x + Virtual Thread 效果还是挺不错的

@chenfang ZGC 吞吐量是会下降不少，分代 ZGC 能稍微好点，但是还是比 G1 要差一点。full GC 的问题更大可能性的还是内存泄露的问题吧，既然使用了高版本 JDK ，那就开个 JFR 呗，然后看看到底是哪里的对象没有被回收掉。我这边的服务类似于数据采集，虽然 QPS 高，但是基本都是朝生夕死，基本没有长期存活的对象，所以目前没观察到 full GC 。

@Rorysky #36 差不多，在充分预热的情况下，高版本 gc 的吞吐量影响几乎可以忽略不计，像是我在 jdk22 用 G1 ，火焰图基本快看不到 GC 的开销了