@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 的开销了

@windghoul #34 JDK17 的是不分代的 ZGC ，吞吐量的影响会更大一点，我自己实测是 7.x%左右，如果对延迟要求不是特别高，JDK17 建议使用 G1 吧

@windghoul 我自己使用情况来看。throughput 的影响，大概 ZGC 分代是 4.x%，G1 是 1.x%。延迟的话，不用说肯定是 ZGC ，基本就是 0ms 。footprint 没测过。我这边服务的堆是 8G 的。目前用的是 JDK 22

用的宁芝静电容，还不错

27 寸，5K ，设置的 2560 x 1400 。

首发 15 pro ，循环 337 ， 健康度 90%。这一年没怎么夜间充电了，都是白天用 MagSafe

1 、在楼上的基础上，可以利用类似 Kafka 的 partition 这种机制，以用户邮箱为 key ，确保同一个用户一定在一个 partition ，然后消费者一个 partition 对应一个 thread ，这就确保一个人的数据只会被一个线程处理
2 、或者利用 Redis 的 SortedSet 数据结构，接收线程接收邮件写入 redis ，一个用户一个 key ，score 用接收的时间之类的。然后定时任务扫描 redis ，使用 lua 脚本结合 zrem+zrange ，一次获取一个人的一部分邮件，然后写 DB 。
3 、总体来说，就是要写入的时候一个用户只被一个 thread 操作，基于这个思路还能有其他的策略

@565656 Apple 抛弃的是 microLED ，这材料，老贵了

Q: 你对目前使用语言的 GC 性能满意吗？
A: 一路从 jdk8 的 parNew+CMS ，升级到 JDK17 的 G1 ，再到今年的 JDK22 的 G1 ，我对 G1 GC 越来越满意了，堆虽然不大但是延迟也很低（< 10ms ）, 吞吐量影响相当小，内存占用也不多，可以说是非常理想了。中途也尝试过 JDK17 的 ZGC 、JDK21 的分代 ZGC ，奈何对吞吐量的影响远大于 G1 ，遂放弃

@ophunter 就是在掌上生活中搜索这个电视，然后商品详情页面有个领券的地方。不过估计是羊毛被薅多了，现在基础价格变高了😂

隔音：优先考虑三玻（一夹胶+一中空），高频/低频噪音应该都能处理比较好，升级版：四玻（两夹胶）
隔热：Low-E ，至少单银 Low-E ，升级版：双银 Low-E
抗风压：内开（牺牲部分室内面积），泰诺风的隔热条，3 条以上的加强筋