https://www.cnblogs.com/ashet/p/17540963.html
我转 PDF 是使用 spire.xls.free 这个 lib 非常好用，你可以试试

牙齿健康不能只关注卫生因素，和基因、饮食结构、作息、甚至心理状态等因素也有关

就像学习时间不能用来单一衡量学习成绩

感觉不可能，就算序列化到 redis 读取，你各个项目本身还是需要各自拥有该实体类。

你的想法就像是大家都在花钱，为什么不花同一份钱

看了下手中的无限鼠标——罗技 M330 ，感觉没有你所说的问题，无卡顿延迟现象、五号电池续航（用好几个月了）
此前一直使用有线，目前的无限鼠标除非游戏等特殊场景，基本使用很难（几乎无法）感受出卡顿

有线鼠标用过好几个品牌，推荐雷蛇蝰蛇系列经典款

@iBUYPOWER 看评论区用 scoop 的确实多，昨天也跟风装上了 o_O

以我个人客观而言，工厂无责，拉卷闸门的厂工也无责。
卷闸门不属于工作操作的器械，也不具有明确危险性。
比如一面墙或一个台阶，有人在这些地方意外受伤，就要因此找业主担责一样，感觉不合理。

@enchilada2020 正解，双拼纠错是人为错误，词库的联想字词功能才算产品缺陷

@Goooooos 你是不是经常导啊？ o_O 全推荐这一类

@xygod 我感觉使用 Windows 软件包管理工具——诸如 Chocolatey 、Scoop 和 Winget……通常是安装非 GUI 软件的场景，这类软件个人认为不用太关心其安装位置，顺便问下你是使用的哪个呢？

感谢 v 友热心回复，使用 scoop 也遇到了问题——Scoop 安装器默认禁用了以管理员权限运行（我哭死）
最后选择使用 winget 挺好用的，一次性 OK

去日本当汁男，赛高！

我选择 wps 和 ms office 都用的盗版，没有这些体验
可以参考 @fimd 的思路，在 Windows Defender 防火墙中禁止 wps 的网络连接（比如我的 iPhone 上装了搜狗输入法，但欧偶尔居然在键盘界面弹广告，因此我直接禁用搜狗输入法的网络权限）

电压力锅确实 OK ，老家就是用的电压力锅煮米饭，口感比电饭煲略佳

20%以下

@txydhr 电池不耐用啊……

@txydhr 真的么🫨还一直期望下部手机入三星来着，主要是现在感觉手机就苹果三星的外观设计上好看些，可惜电池和信号有硬伤

楼上有看到供应商限制频率，接口其实也可以实现以电话号码为基准的限流，避免恶意刷接口。除此之外默认登录项可以展示其他登录方式——密码/三方授权

可以将 GC 理解为打扫 jvm 房间，触发 GC 时会发生 stw （ jvm 的所有进程阻塞——即你所提及进程假死）。GC 的触发分为两种情况：1 、周期性的打扫。2 、突然产生了大量垃圾急需临时大扫除（否则内存将很快超出 OS 分配给 jvm 的总内存）。
jvm 的频繁 GC 通常是第二种情况，而 Full GC 的场景往往是 young generation 和 old generation 区域都需要 clean （也就是整个堆内存区域快使用完了）。

看看 gpt 对你第一行 GC 日志的解释
↓↓↓↓
这段日志是一次垃圾收集（ GC ）事件的记录。让我们逐步分析它：

2024-05-21T18:47:28.916+0800: 371856.391: 表示此日志记录的时间戳，格式为 ISO 8601 ，即 YYYY-MM-DDTHH:mm:ss.sss±hhmm 。

[GC (Allocation Failure): 表示触发 GC 的原因为内存分配失败（ Allocation Failure ）。

ParNew (promotion failed): 4194304K->4635269K(4718592K), 0.4373197 secs: 表示 ParNew （新生代）的 GC 信息，其中：

ParNew: 表示使用的垃圾收集器为 ParNew 。
(promotion failed): 表示新生代中的对象晋升到老年代时出现了晋升失败。
4194304K->4635269K(4718592K): 表示 GC 前新生代的已使用空间和 GC 后的已使用空间，以及新生代总大小。
0.4373197 secs: 表示 GC 所花费的时间。
CMS: 2231901K->2231895K(5242880K), 5.3415522 secs: 表示 CMS （老年代）的 GC 信息，其中：

CMS: 表示使用的垃圾收集器为 CMS 。
2231901K->2231895K(5242880K): 表示 GC 前老年代的已使用空间和 GC 后的已使用空间，以及老年代总大小。
5.3415522 secs: 表示 GC 所花费的时间。
6426200K->6425987K(9961472K): 表示整个堆内存的 GC 信息，其中：

6426200K->6425987K(9961472K): 表示 GC 前堆内存的已使用空间和 GC 后的已使用空间，以及堆内存的总大小。
[Metaspace: 171474K->171474K(1210368K)]: 表示元空间（ Metaspace ）的 GC 信息，其中：

171474K->171474K(1210368K): 表示 GC 前元空间的已使用空间和 GC 后的已使用空间，以及元空间的总大小。
5.7797668 secs: 表示整个 GC 过程所花费的时间。

[Times: user=9.42 sys=0.19, real=5.78 secs]: 表示 GC 的 CPU 时间和实际时间，其中：

user=9.42: 表示用户 CPU 时间。
sys=0.19: 表示系统 CPU 时间。
real=5.78 secs: 表示实际时间。
根据日志内容可以看出，发生了一次新生代和老年代的 GC ，其中 ParNew 阶段由于晋升失败导致了 promotion failed ，而 CMS 阶段则正常完成。整个 GC 过程耗时 5.78 秒，期间堆内存从 6426200KB 降至 6425987KB 。
↑↑↑↑

可以看出每次 GC 所清理的内存空间非常少，6426200-6425987=213KB ，也就是说你的程序中有大量长期一直在使用的对象。

1 、那么是否可以考虑给 jvm 多分配一些内存空间？
2 、这些大量长期使用的对象是如何产生的？是否存在很多内存没有及时释放的代码——比如某些高并发接口内部存在很多内存未及时释放的情况

@gauzung 有效，已成功实现🐮