goroutine相比java 多线程NIO有何优势

NIO（非阻塞IO）是一种IO编程模型，Golang中的IO底层实现方式和java NIO模型一致，通俗点说就是都采用了EPOLL。 你在使用golang读文件的时候，goroutine 会默默的挂起，只是你不知道，当读完毕了，goroutine 再次恢复，但你不用担心，goroutine 的挂起和恢复没有java线程那样可怕，你可以认为goroutine 的挂起和恢复就是保存和恢复几个变量的值，其实也是这样的。

目前成都创新互联公司已为近千家的企业提供了网站建设、域名、虚拟主机、网站托管、服务器托管、企业网站设计、贵定网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。

剩下的就是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还有很长的路要走。

go语言 ioutil.ReadFile 与ioutil.ReadAll差别

   当读取91.2 MB文件时，read1耗时43ms，read2耗时99ms。

查看源码：

读取文件主要是通过 Read(p []byte) (n int, err error) ：

官方文档中关于该接口方法的说明：

结论：

  ReadFile(filename string)方法之所以速度快的原因就是先计算出file文件的size，在初始化对应size大小的buff，传入ReadRead(p []byte) 来读取字节流

golang多线程简单逻辑

实现指定个核心最大化使用，比如核心总数减一。

必要的库。

要使用的cpu数量，建议不全使用。

建立管道。

声明使用的cpu数。

建立互斥关系，本例中主要为了实现所有线程执行完后再执行后续程序。

创建cpu数减1个线程

后面每个任务结束时要done一个wg，这里根据具体情况加，是循环就在每个循环里加，保证后面能全部done即可

没有缓冲的、阻塞式的往管道传递字符串。

Wait是等所有线程都执行完，即增加的数字被全done掉。

关闭管道。

假设已有的函数是ReadLogs，在它的基础上加个Wg加函数名的新函数，我觉得这种方式不改变原有的，比较舒服。

大意是：循环从管道读取字符串，读不到了就跳出循环。

每个ReadLogs()之后加一个wg.Done()，相当于计数减一。

ReadLogs()就是要执行的任务，不再解释。

就是开指定个线程。

管道阻塞传值。

wg同步。

WgReadLogs循环接收。

go多线程传输文件,序列不变

go多线程传输文件，序列不变是真的。线程太占资源，线程调度开销大。go中的goroutine是一个轻量级的线程，执行时只需要4-5k的内存，比线程更易用，更高效，更轻便，调度开销比线程小。

本文名称：go语言多线程读文件 golang多线程
当前链接：http://pwwzsj.com/article/doojcdo.html