会编网络, 不少开发者会掉进一种认知偏差误区里头, 觉得它是能提升程序性能的那种万能解决办法方案。然而在实际的产生场景情形之时, 默认配置设置的可不等于并不等于零损耗消耗, 在高并发场景情况之下甚至会出现性能朝着相反方向倒退的状况, 还比不上不如传统线程池来得稳定高效呢。性能损耗, 主要源自事件循环的底层开销, 其当协程数量达到数千级别时候, 事件循环持续进行轮询, 回调检索, 对象反复创建再销毁等操作, 会累积下大量CPU消耗, 多数人混淆了并发与并行核心区别, 其核心优势是调度海量I/O等待任务, 并非提升计算处理速度, 这也是其无法适配计算密集型场景的关键缘由。实际进行压力测试所获取到的数据, 证实了这样的一种情况: 在短连接的HTTP服务场景当中, 其上下文切换所产生的开销, 能够占据到总的处理时间的百分之二十, 性能方面的表现比不上相应的方案。这样的一种损耗, 并不是设计方面存在缺陷, 而是跨越不同平台进行兼容所带来的一种必然的权衡。为了能够适配与Unix系统不一样的事件模型, 构建起并搭建 了通用的抽象层, 这一层的封装, 自然而然地牺牲掉了一部分运行的效率。在除CPU开销之外的情况中, 内存与GC问题是更易于被忽视掉的。单协程看起来是轻量化的样子, 然而在数万并发的场景之下, 大量的任务对象以及闭包引用会持续地占用内存, 从而大幅度地提升GC回收的频率。当并发数突破五万的时候, GC停顿会从每分钟一次急剧暴涨至每秒数次, 严重地拖累延迟敏感型服务的响应效率。在生产环境里, 要是想着去优化性能, 那最简单且有效的方式便是替换默认事件循环, 转而使用基于libuv优化的那种, 如此能够实现可数倍地提升调度效率。在技术选型方面, 需要进行理性的取舍哟: 对于计算密集型任务而言, 要优先采用多进程架构若遇到常规业务可别盲目地跟着去搞异步, 采用同步代码搭配连接池的方式, 这样运维起来会很简单, 而且稳定性会更强。十分明确其真正适用场景, 仅适合两类业务呢, 一类是存在大量分布式I/O等待调用这种场景, 另一类是需要支撑十万级长连接的高并发服务场景。要精准匹配场景, 还要摒弃技术崇拜, 如此才能发挥异步编程的真正价值。