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，属于疑难杂症，需要结合各种手段。

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

@ybw #29 真的行，用自己的脑子重新思考一下，结合日志，你可以的。

@ybw #24 另一个事实是，如果程序崩溃了，崩溃点和问题所在点也不见得有日志，因为日志系统是程序的一部分。

@ybw #24 所以没必要一行行停下来啊。。停在你认为可能出问题的代码就行了啊。。。

@ybw #20 事实是，你可以。你总能把问题定位到一个范围，然后在几十行代码里跳转。

@ybw #17 可以自己决定在哪一行停下的。

断点调试是很效率很高的 debug 方式，相当于在每一行代码执行之后都打日志。

日志本身也并不能让系统更易于维护，大量的日志反而会拖慢系统的性能。在关键结点准确清晰地打出易于追踪的日志是难度很高的事情，到最后往往是一百行代码几十行日志。

能看懂的代码就是可维护的代码。

从 Buffer 或者流中读数据？这种写法的库 java 里应该没有。。

标记。。

怎么定义`和算法、数学打交道`呢？

分库。。