十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
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还有很长的路要走。
当读取91.2 MB文件时,read1耗时43ms,read2耗时99ms。
查看源码:
读取文件主要是通过 Read(p []byte) (n int, err error) :
官方文档中关于该接口方法的说明:
结论:
ReadFile(filename string)方法之所以速度快的原因就是先计算出file文件的size,在初始化对应size大小的buff,传入ReadRead(p []byte) 来读取字节流
实现指定个核心最大化使用,比如核心总数减一。
必要的库。
要使用的cpu数量,建议不全使用。
建立管道。
声明使用的cpu数。
建立互斥关系,本例中主要为了实现所有线程执行完后再执行后续程序。
创建cpu数减1个线程
后面每个任务结束时要done一个wg,这里根据具体情况加,是循环就在每个循环里加,保证后面能全部done即可
没有缓冲的、阻塞式的往管道传递字符串。
Wait是等所有线程都执行完,即增加的数字被全done掉。
关闭管道。
假设已有的函数是ReadLogs,在它的基础上加个Wg加函数名的新函数,我觉得这种方式不改变原有的,比较舒服。
大意是:循环从管道读取字符串,读不到了就跳出循环。
每个ReadLogs()之后加一个wg.Done(),相当于计数减一。
ReadLogs()就是要执行的任务,不再解释。
就是开指定个线程。
管道阻塞传值。
wg同步。
WgReadLogs循环接收。
go多线程传输文件,序列不变是真的。线程太占资源,线程调度开销大。go中的goroutine是一个轻量级的线程,执行时只需要4-5k的内存,比线程更易用,更高效,更轻便,调度开销比线程小。