Go语言出现后，Java还是好选择吗？
|
我们可以看到由于这种封装导致的eventLoop的割裂，即便完全使用回调的形式，我们处理请求时多多少少要在多个eventLoop/线程池之间传递，而每个线程又都没法跑到一个较满的程度，导致频繁地进入os调度。与上述的每个线程不太需要阻塞原则相违背。因此虽然减少了线程数，节约了内存，但是我们得到的性能收益变得很有限。 完全从零开始开发 对于一个功能有限的新应用(比如nginx只支持http和mail协议)来说我们可以不依赖现有的组件来重新写应用。比如我们可以基于Netty写一个数据库代理服务器，与客户端的连接以及与真正后端数据库的连接共享同一个eventloop。 这样精确控制线程模型的应用通常可以获得很好的性能，通常性能是可以高于通过非异步程序转协程的，原因如下：
但是使用协程依旧有一个优势：对于jdk中无处不在的synchronized块，wisp可以正确地切换调度。 适应的Workload 基于上述的背景，我们已经知道Wisp或者其他各种协程是适用于IO密集Java程序设计的。否则线程没有任何切换，只需要尽情地在CPU上跑，OS也不需要过多的干预，这是比较偏向于离线或者科学计算的场景。 在线应用通常需要访问RPC、DB、cache、消息，并且是阻塞的，十分适合使用Wisp来提升性能。 最早的Wisp1也是对这些场景进行了深度定制，比如hsf接受的请求处理是会自动用协程取代线程池，将IO线程数量设置成1个后使用epoll_wait(1ms)来代替selector.wakeup()，等等。因此我们经常受到的一个挑战是Wisp是否只适合阿里内部的workload？
为了证明这一点，我们使用了web领域最权威的techempower benchmak集来验证，我们选择了com.sun.net.httpserver、Servlet等常见的阻塞型的测试(性能不是最好，但是最贴近普通用户，同时具备一定的提升空间)来验证Wisp2在常见开源组件下的性能，可以看到在高压力下qps/RT会有10%~20%的优化。 Project Loom Project Loom作为OpenJDK上的标准协程实现很值得关注，作为java开发者我们是否应该拥抱Loom呢？ 我们首先对Wisp和Loom这里进行一些比较： 1）Loom使用序列化的方式保存上下文，更省内存，但是切换效率低。 2）Wisp采用独立栈的方式，这点和go类似。协程切换只需切换寄存器，效率高但是耗内存。 3）Loom不支持ObectMonitor，Wisp支持。
4）Wisp支持在栈上有native函数时切换(反射等等)，Loom不支持。
总根据我们的判断，Loom至少还要2年时间才能到达一个稳定并且功能完善的状态。Wisp的性能优秀，功能要完整很多，产品本身也要成熟很多。Loom作为Oracle项目很有机会进入Java标准，我们也在积极地参与社区，希望能将Wisp的一些功能实现贡献进社区。 同时Wisp目前完全兼容Loom的Fiber API，假如我们的用户基于Fiber API来编程，我们可以保证代码的行为在Loom和Wisp上表现完全一致。 FAQ 协程也有调度，为什么开销小？ 我们一直强调了协程适用于IO密集的场景，这就意味了通常任务执行一小段时间就会阻塞等待IO，随后进行调度。这种情况下只要系统的CPU没有完全打满，使用简单的先进先出调度策略基本都能保证一个比较公平的调度。同时，我们使用了完全无锁的调度实现，使得调度开销相对内核大大减少。 Wisp2为什么不使用ForkJoinPool来调度协程？ ForkJoinPool本身十分优秀，但是不太适合Wisp2的场景。 为了便于理解，我们可以将一次协程唤醒看到做一个Executor.execute()操作，ForkJoinPool虽然支持任务窃取，但是execute()操作是随机或者本线程队列操作(取决于是否异步模式)的，这将导致协程在哪个线程被唤醒的行为也很随机。 在Wisp底层，一次steal的代价是有点大的，因此我们需要一个affinity，让协程尽量保持绑定在固定线程，只有线程忙的情况下才发生workstealing。我们实现了自己的workStealingPool来支持这个特性。从调度开销/延迟等各项指标来看，基本能和ForkJoinPool打平。 还有一个方面是为了支持类似go的M和P机制，我们需要将被协程阻塞的线程踢出调度器，这些功能都不适宜改在ForkJoinPool里。 如何看待Reactive编程？ Reactive编程模型已经被业界广泛接受，是一种重要的技术方向；同时Java代码里的阻塞也很难完全避免。我们认为协程可以作为一种底层worker机制来支持Reactive编程，即保留了Reactive编程模型，也不用太担心用户代码的阻塞导致了整个系统阻塞。 这里是Ron Pressler最近的一次演讲，作为Quasar和Loom的作者，他的观点鲜明地指出了回调模型会给目前的编程带来很多挑战 。 Wisp经历了4年的研发，我将其分为几个阶段： 1）Wisp1，不支持objectMonitor、并行类加载，可以跑一些简单应用； 2）Wisp1，支持了objectMonitor，上线电商核心，不支持workStealing，导致只能将一些短任务转为协程(否则workload不均匀)，netty线程依旧是线程，需要一些复杂且trick的配置； 3）Wisp2，支持了workStealing，因此可以将所有线程转成协程，上述netty问题也不再存在了。 目前主要的限制是什么？ 目前主要的限制是不能有阻塞的JNI调用，wisp是通过在JDK中插入hook来实现阻塞前调度的，如果是用户自定义的JNI则没有机会hook。 最常见的场景就是使用了Netty的EpollEventLoop： 1）蚂蚁的bolt组件默认开启了这个特点，可以通过-Dbolt.netty.epoll.switch=false 来关闭，对性能的影响不大。 2）也可以使用-Dio.netty.noUnsafe=true , 其他unsafe功能可能会受影响。 3）(推荐) 对于netty 4.1.25以上，支持了通过-Dio.netty.transport.noNative=true 来仅关闭jni epoll，参见358249e5 （编辑：厦门网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
