剩下的就是goroutine 和 java线程的区别了，goroutine是用户态的线程切换，java采用的是系统线程切换，用汇编语言描述是一个(java)调用int 80软中断,一个没有。 意味着goroutine更轻量级，可以同时相应成千上万的线程切换，java你创造上千个线程就有些吃力了。
因为java线程不能创造过多的线程，如果同时处理上万上千的请求时候，就要考虑在几十个线程来处理上万上千的请求，这就出现了很多请求和线程不可能一一对应，所以通常做法是每个线程分别处理单个请求各个阶段。好比流水线，请求是要加工的商品，每个线程处理一道工序，这样做的好处是每人都做自己熟悉的，对于程序来说每个线程执行的代码永远都是自己很短的一块，这样根据局部优化原理，更具备CPU，内存亲和力，利于JIT。说这样多，就是说如果线程和请求不能一一对应，流水线式的并发编程很麻烦，阅读性也很差，通常是线程A里面一段逻辑代码，线程B又有另一处处理的逻辑代码。
由于goroutine 的轻便，你可以将请求和goroutine 一一对应起来，不用考虑将请求在线程之间换来换去，只关心你的业务逻辑，这就是goroutine 的好处。
总结：
golang的goroutine让你比java更容易编写并发程序，但性能不会有差别（目前来说，golang性能还不能和java比，看过代码就知道了，GC弱到爆），代码不会减少，该写的逻辑还得写。ps，其实golang的(sched)go程切换代码虽然原理和java的fork-join框架一样，但是fork-join比golang的sched代码牛逼不少，开始膜拜Doug Lea吧，golang还有很长的路要走。
Java NIO框架MINA用netty性能和链接数、并发等压力测试参数好于mina。\x0d\x0a\x0d\x0a特点：\x0d\x0a1。NIO弥补了原来的I/O的不足，它再标准java代码中提供了高速和面向块的I/O\x0d\x0a原力的I/O库与NIO最重要的区别是数据打包和传输方式的不同，原来的I/O以流的方式处理数据，而NIO以块的方式处理数据；\x0d\x0a\x0d\x0a2.NIO以通道channel和缓冲区Buffer为基础来实现面向块的IO数据处理，MINA是开源的。\x0d\x0a\x0d\x0aJavaNIO非堵塞应用通常适用用在I/O读写等方面，我们知道，系统运行的性能瓶颈通常在I/O读写，包括对端口和文件的操作上，过去，在打开一个I/O通道后，read()将一直等待在端口一边读取字节内容，如果没有内容进来，read()也是傻傻的等，这会影响我们程序继续做其他事情，那么改进做法就是开设线程，让线程去等待，但是这样做也是相当耗费资源的。\x0d\x0a\x0d\x0aJava NIO非堵塞技术实际是采取Reactor模式，或者说是Observer模式为我们监察I/O端口，如果有内容进来，会自动通知我们，这样，我们就不必开启多个线程死等，从外界看，实现了流畅的I/O读写，不堵塞了。\x0d\x0a\x0d\x0aJava NIO出现不只是一个技术性能的提高，会发现网络上到处在介绍它，因为它具有里程碑意义，从JDK1.4开始，Java开始提高性能相关的功能，从而使得Java在底层或者并行分布式计算等操作上已经可以和C或Perl等语言并驾齐驱。\x0d\x0a\x0d\x0a如果至今还是在怀疑Java的性能，说明思想和观念已经完全落伍了，Java一两年就应该用新的名词来定义。从JDK1.5开始又要提供关于线程、并发等新性能的支持，Java应用在游戏等适时领域方面的机会已经成熟，Java在稳定自己中间件地位后，开始蚕食传统C的领域。\x0d\x0a\x0d\x0a原理：\x0d\x0aNIO 有一个主要的类Selector,这个类似一个观察者，只要我们把需要探知socketchannel告诉Selector,我们接着做别的事情，当有事件发生时，他会通知我们，传回一组SelectionKey,我们读取这些Key,就会获得我们刚刚注册过的socketchannel,然后，我们从这个Channel中读取数据，放心，包准能够读到，接着我们可以处理这些数据。Selector内部原理实际是在做一个对所注册的channel的轮询访问，不断的轮询(目前就这一个算法)，一旦轮询到一个channel有所注册的事情发生。比如数据来了，他就会站起来报告，交出一把钥匙，让我们通过这把钥匙来读取这个channel的内容。在使用上，也在分两个方向，一个是线程处理，一个是用非线程，后者比较简单。
