当年信了 V 站的邪，用 status_code 来定义业务异常，加了好多自定义的状态码，很蛋疼，想换回去。

为啥你们都准备发货了+1

看数据特征了。

像延时这种长尾效应明显的适合用指数，2 、4 、8 、16 等；
均匀分布的数据就你这种就好

最好是有点挑战性的东西。

aDEwMjMyNjMyMDRAZ21haWwuY29t

咦为啥我印象中有个按钮是永久推迟更新（不过我比较喜欢追新就没点

@xxiali #14 嗷，那算下来差不多，我当时冬季燃气费就花了 3K 。。这还是紧着烧

@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 呢