@xxiali #12 看咋用吧。。不过烧暖气我不大相信只有 200/月

mailspring?

钉钉也没适配呢，着啥急

@no1xsyzy #141 激进非抢占和消极非抢占都是什么意思呀，第一次听到这俩名词，搜了一下也没搜到，能给个链接学习一个吗

你说的这算什么缺点啊。。。哪怕是纯多线程，你写出了一个死循环或者死锁，就能保证它只阻塞一个线程不影响其他线程？
还有，异步和多线程并不存在任何冲突，思维不要被单一语言限制，从原理上讲这俩就不是一个维度的东西。

目前的操作系统只提供了多线程和多进程的调度支持，如果要实现异步，要么是如你所言线程池（单线程也是一种线程池）+回调的方式，要么是 go 这种自行实现了一套协程的调度模型，但这两种最终的落脚点都在操作系统的线程上，因此就目前而言，各种异步编程的实现方式都是对多线程去阻塞的优化，目标还是完美利用多核算力。

一般而言，公认异步的缺点主要有以下两种：
1. 对同步代码的破坏性改动，绝大多数异步 API 都具有传染性，类似各种语言的 async 关键字，各种异步库的 Future/Promise/Mono，都不可避免通过函数签名的方式传染调用方（ go 这方面就好很多）；
2. 复杂调度和竞争导致的延时，同步可以不用做其他事专心等阻塞逻辑的结果就好，异步就得等线程 /协程调度的结果，让你这个回调执行才能轮到执行，当并发量大的时候长尾效应还是很严重的。

@Joker123456789 #26 然后两个组件的网络消息共用一个线程池。。。

@Joker123456789 #3 推广的事就不提了。其实上午我怀着相当大的期待阅读了你的部分源码，因为是把它当作 Netty 的替代去看待的，所以不自觉地把它和 Netty 做了一些对比，如果有冒犯的地方向你道歉。emmmmm，那就不提 Netty 说几个有可能提升你这个项目质量的点

1. 对协议的抽象不够，假如某个业务想把 http 换成 udp，看不出有什么平滑切换的可能性；
2. 和线程模型绑得太死，市面上鲜少有这种自带线程模型的网络库；
3. 没有性能测试数据，也无从得知你这个网络库的性能怎么样；
4. 代码风格值得优化，起码把 JavaDoc 按规范写了吧；
5. 缺乏面向对象设计，似乎从未考虑过一个服务的两个组件同时使用你这个网络库的任何可能性；

1. 推广就发推广；
2. 看来看去看不出来比 netty 高在哪儿

@GM #4 为啥迅雷批量下载能规避限速的问题呢

曾经在这个小区住过，冬天被冻成🐶。。。因为没有供暖，只能自己烧燃气灶，然鹅燃气费太贵

倒还好，1.5G ，没楼主这么夸张
https://i.imgur.com/8PrNVB9.png

为啥这么讨厌 MAU 呢

@Moyudawang #18 没有这个选项呢。

@TheWidowMaker #29 java 自带的 Objects.requireNonNull，Guava 的 Preconditions.chechNotNull 都是抛出空指针异常，这俩 API 的设计者都觉得指针是空的抛个空指针就可以，有什么问题呢？

感觉没啥毛病啊。。入參不合法还不让抛异常了吗

@iminto #4 的确，guava 的 android 和 jre 版本更多在于编码风格和特定于 android 的优化。android 在编写和编译的层面也兼容某一个特定的 java 版本，可以说合法的 java 代码就是合法的 android 代码。不同的是运行时。

@abcbuzhiming #2 最著名的大概就是 guava 了

显然没有，语法层面的兼容都没有做到，所以很多库会同时有 jre 版本和 android 版本。另外，Google 也复用了一大堆 JDK 的原始代码，后来因为官司问题都替换成了自己的实现而已。