@also24 #53 哦哦 我应该是回复错人了
我知道有 retrieve 这个说法，但是 wiki 里也没写这种说法里的出处啊。。。wiki 里也说了，类似的概念有好多种讲法，并不是每一种都提供了出处。。

@also24 #49
@yjxjn #50
所以二位口口声声说 read 是错的。。出处呢

@iBenlim #27
@yjxjn #41
有出处吗，英文维基是这样写的
https://www.wikiwand.com/en/Create,_read,_update_and_delete

写一段 groovy 代码把版本号查出来写到配置文件里。。

了解一下转义。。

用 redis 做。。

1. 默认配置和分布式服务的需求差异比较大；
2. 调优难，往往需要修改操作系统参数，而这会影响一堆服务；
3. 扩展难度大，比如很多分布式服务的心跳包会带数据；
4. 只能检测连接的活性，而无法检测服务的可用性；
5. 处理事件不方便，很多语言的标准库提供的 API 很难用；
6. 没有收益，TCP 自带的保活相比应用层自己实现，没有效率优势；

@amiwrong123 #15 你这样写没办法出发自动类型转换（你这个只不过是把 HashMap 自带的 get 方法换了个写法）

因为 HashMap.get(Object)接受任意类型的参数，当传入基本数据类型时，会触发自动装箱。

如果你声明一个这样的方法，用来替换 HashMap.get ，就会先触发类型转换，然后触发自动装箱；

```java
static <T> T get(HashMap<?, T> map, int key) {
return map.get(key);
}
```

java 貌似不支持同一个位置既自动类型转换又自动装箱。。

二婚市场？

@noble4cc #22 是的，线程池在并发量大的情况下不如协程。所以这种情况下会做一些设计，比如把发消息和收消息分开，一个线程池专门发，一个线程池专门处理收消息，也就是 NIO 的思路。。

CompletableFuture 自带一个线程池，自己写的话可能比协程别扭一点，但是效率差不多

线程池+CompletableFuture+聚合操作

@javaWeber #1 如果不知道用什么好，就用 orThrow，抛出异常。

有人已经写了一个 pr 。。。

@pinews #24 给你举几个一旦闭源就会失去生命力的顶级软件例子；

1. java，无论是 jvm，还是基础库，都有甲骨文、谷歌、微软、华为等顶级开发商的卓越贡献，除了开源，没有其他因素能得到这么多公司的贡献，而 java 的类库天然就是开放源代码的，没有开源，就没有现在的 java 生态；
2. Linux，任何人都可以放心使用 Linux，因为每个人都知道 Linux 的代码被无数程序员 review 过无数次，这显然是开源的好处；
3. Chromium 和 AOSP，Chrome 和 Android 的成功离不开这两个开源项目，它们繁荣的插件和扩展生态更是和开源密切相关；

我不想争论开源和闭源的优劣，一个显而易见的事实是闭源更能赚钱，如果说运营的话，只有能赚钱的东西才有运营的价值。看不懂你这个`运营`是指什么，如果是指社区的话，那开源天生就有优势。


"""
说白了，开源就是运营和竞争能力不足，去争取比他们还差的人
"""

这句话暴露了你的无知和自大，开源软件的作者和社区的贡献者，大多数也在商业公司开发闭源软件，他们本人的能力如何可以通过他们提交的代码得窥一二，他们编写的开源软件的社区运营和市场竞争力，显然并不比商业软件稍逊。

`说白了，开源就是运营和竞争能力不足，去争取比他们还差的人`。。。

这句话完全是错的，鲜有能和顶级开源软件抗衡的同类商业软件。

程序退出是因为运行到了终点。。。你可以起一个线程池来处理事件。。

@also24 #33 我回顾了一下我的措辞，我觉得还是比较准确和中肯的。

楼主原话是`改 bug 的方式`，已经发现了有 bug，甚至开始尝试定位，这种情况下断点调试的效率很高。

我从没有说断点调试是优于日志的 debug 方式，只是在改 bug 的时候效率更高。

楼上有很多人认为日志有助于提高系统的可维护性，很大程度上日志有变量监视器和注释的作用，我也并没有否认，我只是说，放弃使用调试器，想要单凭日志来 debug，甚至追求那些所谓的`额外收益`，是一件南辕北辙的事情。

我看到有位仁兄 @ybw 觉得调试要一行一行看，觉得很难定位到一个问题存在的范围，可能代表了某些人的想法。可是能知道在那个地方添加日志，怎么就想不起来在那个地方下断点呢？断点相当于一个运行期间可以随时修改，完整打印所有变量内容甚至堆栈细节的日志，所以说 debugger 的效率比查日志高。

而你所说的，基本上是废话，每个人都知道日志不可或缺，甚至在有些场景是唯一的方案。对代码熟悉的人，可以更精确的下断点，但只看日志就确定问题的人，一定熟悉代码。

查 bug 的常规思路，知道某个地方有 bug，然后开始浏览日志试图定位问题，可能 40%的 bug 就能看出来了。看不到问题，开始复现 bug，剩余 90%以上的 bug 都是可以复现的，对可以复现的 bug 而言，断点调试是效率最高的调试方式了，剩下的 bug，属于疑难杂症，需要结合各种手段。

而你所谓`日志为主的处理思路`，对真正的疑难杂症毫无作用，所谓的`整体性`，是以程序运行的效率为代价的，`更多额外的收益`只是臆想，任何应用广泛的软件设施，对日志的使用都是很克制的。