2 难道不是数据库 bug 吗，自己内部都不一致了

这个东西吧，你要是说把 Linux 放到那个场景不需要 EDR 软件，其实 Windows 也可以不需要。到时候写坏了该崩还是崩。
@james122333
话说先行 Linux 发行版有办法配置成发生故障时自动切换内核吗

这种，直接用汉字不行吗…无非就是打字麻烦点，需要注意 Unicode 的亿点问题，总比首字母查表猜含义强…
唉…倒是忘了有些技术标准不允许非 ASCII 字符…

按三楼的方法，把这块切分出去，计数/计内存重启吧。很多解决不了的（不一定是 bug ）内存泄漏都会采用这种方法（举个例子 gradle ）。
不过这次之后你们应该会优化公司流程吧，涉及到有经济损失风险的变更竟然不提前测试😵‍💫。

JVM 的初始内存消耗就是很大，它提供了 go runtime 缺失的太多功能。至于跑起来的话，虽然 JVM footprint 偏大，但实际内存消耗还是要看程序怎么写。

这个是类似 JetBrains 系的 Structure 窗口吗

一般来说，PostgreSQL 本身对「集群」的支持，只有「复制」这一个功能。其他的，读写分离、负载均衡、故障转移，全都依靠其他中间件实现。

如果要增加超时机制，就必须考虑如果程序因为种种原因暂停（垃圾回收、VM 迁移）导致锁超时，恢复运行后，“以为”自己还持有锁会导致何种问题。考虑的最后往往是别用这个破锁了。

这个东西用不用看一眼 robots.txt 啊

cn 后缀，他连域名都懒得手打一遍

letsencrypt

@diagnostics 我只有一个迫不得已用 Maven 的项目用了 Maven ，那是因为目标平台用了 OSGi ，相关构建插件在 Gradle 中非常不成熟。我观测的也是，Maven 在构建和配置缓存的利用上非常不优化，我不确定 Maven 平台有没有提供这种能力。
Gradle 的一个大问题在于冷启动实在是太慢了，如果使用了 buildSrc (aka. convention precompiled plugin) 问题就更加严重，偏偏官方鼓励使用这个···

此外就是考虑到 Kotlin 这种编译比较缓慢的语言，我在实践中倾向于让每一个模块保持很小的体积，同时让依赖树尽量扁平，这样，IDE 更流畅，Gradle 自身的并发执行任务的能力也对我有很大帮助。

@31415926535x 模块之间的紧密度，在切分仓库和单一模块之间还有一个层级，这个层级刚好使用 Maven 的多模块和 Gradle 的多 Project 能力处理。每一个“模块”是一个编译单元，有时候编译单元的切分是必须的。
一般来说一个稍微复杂点的可扩展功能就必须切分为至少两个模块，模型与实现，比如一个叫 xxx-api 另一个叫 xxx-core 之类的。这时，两个模块都会被存储到制品仓库（比如 Maven Central ），而扩展模块只需要依赖 xxx-api 即可。

@31415926535x 多个版本库之间管理是额外的成本，git submodule 并不好用，特别是模块间关系紧密，连版本号都完全统一时。

@zhenjiachen Gradle 主要是冷启动比较慢，很大程度上这还是 Kotlin 导致的（因为要编译 kts 脚本和 buildSrc ，Kotlin 编译慢的离谱），后续的话，任务缓存和 daemon 等等机制理论上是非常高效的

@duanluan

> 2. 需要换个插件，description 、scm.url 等必填，不再支持快照版本。

破坏掉兼容性这一点太令人难以接受了，好在应该在未来相当一段时间旧的设施仍然可以使用。

@codingmiao 这个我倒是没有遇到过，Gradle 因为 API 经常不兼容，所以基本上都通过 wrapper 强行指定版本了······反而是 Maven 因为没这个问题，被人用上古版本炸过。