Golang并发 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Programming - 葵花宝典

Golang并发

Golang并发# Programming - 葵花宝典

b*12018-07-13 07:07

1 楼

6月初递交的B2延期，但是很担心因为没有提供返程机票、信中也没有写为什么在延期
后一定回国，所以很担心延期被拒，虽然这是第一次申请延期，但如果被拒，会跟很多
计划产生矛盾，相当局促。所以不想冒险了，还是递交绿卡申请。这种情况，是否需要
先撤销B2的延期申请？这对绿卡申请有负面影响嘛？
另外，因为我父亲还在国内，他来美的签证8月底到期，是不是如果我母亲申请了绿卡
，我父亲最好利用手里有的签证来美，否则如果再次申请签证，会因为我母亲已经提交
绿卡申请而影响我父亲的B2签证申请？
多谢大家支招！

w*22018-07-13 07:07

2 楼

NSC，RD11/08,ND11/14,Combo cards 12/17/2011.供大家参考。
1.现有一个问题，下个月想回国过春节，想买到北京的往返机票，可是在此版看到说在
北京用Combo card 不让登机返美，那怎么办？
2.还有返美时除了护照和Combo card,还需要带什么文件？多谢！

c*t2018-07-13 07:07

3 楼

其实就是，而且只是，宣传的原因。以前国人刚看到西方人的时候，描述是高鼻深目，
外形似鬼。要有多难看就有多难看。现在呢？看看好莱坞的大片吧，看多了，里面的帅
哥就真成帅哥了，印到你的脑子里面去了，成了你的审美观了。这个我有切身体会。本
来印象里某人很普通的长相，就因为某电影里面的某明星长得那样，结果下次在看到他
，就觉得好多了。
就是个文化强势的作用。在美国，李小龙比成龙对华人婚嫁地位的正面作用要大得多。
我走在路上还常常有老黑笑着对我表示友好，一边做出李小龙的动作，嘴里说bruce
Lee。华人不应该光顾赚钱，还需要拍片，拍不了片也要像黑人那样闹事，叫别人拍他
的正面形象。电影里面黑人总统都有多少了？黑人英雄也不少。黄人呢？还需要更多李
小龙。
香港的电影电视对大陆也有这样的效果。当时正好是我青少年时期，看多了香港影视，
南方女子就看起来很美了。国内上演西方大片，当然国内长大的就觉得西方人帅。美国
上演的片子里们东方人都是猥琐男，那当然美国长大的女孩就爱不起来东方人。

g*t2018-07-13 07:07

4 楼

刚看到有个文章说。golang 在运行时给用户态线程分配资源。因为golang可以观察到
一切信息，所以不需要分配资源的线程就不分配。jvm by default看不到这些信息。所
以先天受限制，只能都分配资源。所以二者的并发处理，类似于不同假设条件下的优化
。先天golang的设
置占优势。
这个说法似乎颇有道理，大家怎么看？

n*n2018-07-13 07:07

5 楼

可以申请签证吧，用新AP有风险，用签证回美国总没有理由拦吧。

l*p2018-07-13 07:07

6 楼

人类社会的任何文化现象都是被社会建构的。
你们有种就去和美国的女权主义理论家一样，写几本类似“第二性”的批判一下，深入
思考一下；再有种，就和女人游行烧乳罩扔高跟鞋一样，你们也搞个游行烧电影海报，
但麻烦不要在论坛上攻击女人。
而事实上就是，现在女人以瘦，白为美，这也是文化，媒体建构的结果。君不见唐朝还
以肥为美么。可我们也没见到那些被当代文化定义为“丑女”的女人，在网上气急败坏
的攻击选择美女的男人们吧？
在社会上遭遇的不公，不是你们变得尖酸刻薄，内心阴暗不善良的理由。

f*22018-07-13 07:07

7 楼

jvm怎么看不到os线程了？

a*d2018-07-13 07:07

8 楼

NIU不是要跟进这件事情吗，不知有啥进展。

c*t2018-07-13 07:07

9 楼

生物界，基本上是有某个手段可以成功，那个手段就会被利用。如果攻击女性WF可以减
少女性WF，那么对这种行为也就见怪不怪。

w*z2018-07-13 07:07

10 楼

我也看到了，java 每个线程给 4m stack. go routine idle 就不要。但go routine
啥都不干，开那么多有啥意义。要在正真高并发，处理任务的时候比较才有意义。

：刚看到有个文章说。golang 在运行时给用户态线程分配资源。因为golang可以观察到
：一切信息，所以不需要分配资源的线程就不分配。jvm by default看不到这些信息。
所以先天受限制，只能都分配资源。所以二者的并发处理，类似于不同假设条件下的优
化。先天golang的设

C*e2018-07-13 07:07

11 楼

人做为一个独立个体，要有自己的思想，不是说流行什么就相信，ok。。。。
所谓的时尚界流行瘦，你就减肥？ft。。。。那西方流行tan，你还喜欢白？
不是说存在的就会合理，要批判吸收
如果读书读到本科以上了，要学会独立思考
看你的贴，估计你是传媒相关类的master，爱美的同时，注意内在修为吧

【在 l******p 的大作中提到】

: 人类社会的任何文化现象都是被社会建构的。
: 你们有种就去和美国的女权主义理论家一样，写几本类似“第二性”的批判一下，深入
: 思考一下；再有种，就和女人游行烧乳罩扔高跟鞋一样，你们也搞个游行烧电影海报，
: 但麻烦不要在论坛上攻击女人。
: 而事实上就是，现在女人以瘦，白为美，这也是文化，媒体建构的结果。君不见唐朝还
: 以肥为美么。可我们也没见到那些被当代文化定义为“丑女”的女人，在网上气急败坏
: 的攻击选择美女的男人们吧？
: 在社会上遭遇的不公，不是你们变得尖酸刻薄，内心阴暗不善良的理由。

g*t2018-07-13 07:07

12 楼

Idle 的不占资源，这个似乎也是有意义的
如果这种情况确实是一个user case能让jvm无法给别的线程分资源的话

: 我也看到了，java 每个线程给 4m stack. go routine idle 就不要。
但go
routine

: 啥都不干，开那么多有啥意义。要在正真高并发，处理任务的时候比较
才有意
义。

: ：刚看到有个文章说。golang 在运行时给用户态线程分配资源。因为
golang可
以观察到

: ：一切信息，所以不需要分配资源的线程就不分配。jvm by default看不
到这些
信息。

: 所以先天受限制，只能都分配资源。所以二者的并发处理，类似于不同假
设条件
下的优

: 化。先天golang的设

【在 w**z 的大作中提到】

: 我也看到了，java 每个线程给 4m stack. go routine idle 就不要。但go routine
: 啥都不干，开那么多有啥意义。要在正真高并发，处理任务的时候比较才有意义。
:
: ：刚看到有个文章说。golang 在运行时给用户态线程分配资源。因为golang可以观察到
: ：一切信息，所以不需要分配资源的线程就不分配。jvm by default看不到这些信息。
: 所以先天受限制，只能都分配资源。所以二者的并发处理，类似于不同假设条件下的优
: 化。先天golang的设

l*p2018-07-13 07:07

13 楼

我讨论的是群体现象，是宏观的角度
你们这些WSN总是要把这些话题扯到个人身上。
基本的人文素养的训练都无。

【在 C*********e 的大作中提到】

: 人做为一个独立个体，要有自己的思想，不是说流行什么就相信，ok。。。。
: 所谓的时尚界流行瘦，你就减肥？ft。。。。那西方流行tan，你还喜欢白？
: 不是说存在的就会合理，要批判吸收
: 如果读书读到本科以上了，要学会独立思考
: 看你的贴，估计你是传媒相关类的master，爱美的同时，注意内在修为吧

g*t2018-07-13 07:07

14 楼

就是说不管 idle与否都4M

: jvm怎么看不到os线程了？

【在 f******2 的大作中提到】

: jvm怎么看不到os线程了？

i*a2018-07-13 07:07

15 楼

顶这个. 很多人就是势力眼.
国女99%不会tan的. 还有欧美好多TOP男MODEL眼睛偏扁, 不是越大越圆越帅.

【在 C*********e 的大作中提到】

M*t2018-07-13 07:07

16 楼

又不是真的给4m
page table做了个4m的entries 而已
实际用不了多少

【在 g****t 的大作中提到】

: 就是说不管 idle与否都4M
:
:
: jvm怎么看不到os线程了？
:

w*g2018-07-13 07:07

17 楼

你这个描述太抽象，我其实理解不了。你要有原文链接的话麻烦贴一下。
感觉跟王垠当年吹的ext3文件系统能自动优化所以没有碎片这套理论很像。
我感觉golang和jvm的runtime所谓的分配资源，都是按请求来的。请求多少
就分配多少，没啥观察到观察不到的。

【在 g****t 的大作中提到】

: 刚看到有个文章说。golang 在运行时给用户态线程分配资源。因为golang可以观察到
: 一切信息，所以不需要分配资源的线程就不分配。jvm by default看不到这些信息。所
: 以先天受限制，只能都分配资源。所以二者的并发处理，类似于不同假设条件下的优化
: 。先天golang的设
: 置占优势。
: 这个说法似乎颇有道理，大家怎么看？

g*t2018-07-13 07:07

18 楼

我这不是描述抽象。是我压根不懂这些技术细节。
所以只能凭印象说一下。哈哈。原文里面是下面一段。
https://rcoh.me/posts/why-you-can-have-a-million-go-routines-but-only-1000-
java-threads/
Supporting truly massive concurrency requires another optimization: Only
schedule a thread when you know it can do useful work! If you’re running
that many threads, only a handful can be be doing useful work anyway. Go
facilitates this by integrating channels and the scheduler. If a goroutine
is waiting on a empty channel, the scheduler can see that and it won’t run
the Goroutine. Go goes one step further and actually sticks the mostly-idle
goroutines on their own operating system thread. This way the (hopefully
much smaller) number of active goroutines can be scheduled by one thread
while the millions of mostly-sleeping goroutines can be tended to separately
. This helps keep latency down.
Unless Java added language features that the scheduler could observe,
supporting intelligent scheduling would be impossible. However, you can
build runtime schedulers in “user space” that are aware of when a thread
can do work. This forms the basis for frameworks like Akka that can support
millions of actors6

: 你这个描述太抽象，我其实理解不了。你要有原文链接的话麻烦贴一下。

: 感觉跟王垠当年吹的ext3文件系统能自动优化所以没有碎片这套理论很像。

: 我感觉golang和jvm的runtime所谓的分配资源，都是按请求来的。请求多少

: 就分配多少，没啥观察到观察不到的。

【在 w***g 的大作中提到】

: 你这个描述太抽象，我其实理解不了。你要有原文链接的话麻烦贴一下。
: 感觉跟王垠当年吹的ext3文件系统能自动优化所以没有碎片这套理论很像。
: 我感觉golang和jvm的runtime所谓的分配资源，都是按请求来的。请求多少
: 就分配多少，没啥观察到观察不到的。

w*g2018-07-13 07:07

19 楼

massive concurrency本身是一个站不住脚的需求。
假设一台牛x的服务器，有两个U，每个64线程，一共128线程正在运行。
如果是操统线程，1/10 active，一共调度1280个线程，完全没有压力。
那么对于go来说，得12800个线程才称得上massive parallel。
而且最后cooperative threading在latency上拼不拼得过操统线程还
不一定。

run
idle

【在 g****t 的大作中提到】

: 我这不是描述抽象。是我压根不懂这些技术细节。
: 所以只能凭印象说一下。哈哈。原文里面是下面一段。
: https://rcoh.me/posts/why-you-can-have-a-million-go-routines-but-only-1000-
: java-threads/
: Supporting truly massive concurrency requires another optimization: Only
: schedule a thread when you know it can do useful work! If you’re running
: that many threads, only a handful can be be doing useful work anyway. Go
: facilitates this by integrating channels and the scheduler. If a goroutine
: is waiting on a empty channel, the scheduler can see that and it won’t run
: the Goroutine. Go goes one step further and actually sticks the mostly-idle

m*n2018-07-13 07:07

20 楼

如果换作Alpha Go那种计算线程呢？
是不是只能每个核一个进程了？

【在 w***g 的大作中提到】

: massive concurrency本身是一个站不住脚的需求。
: 假设一台牛x的服务器，有两个U，每个64线程，一共128线程正在运行。
: 如果是操统线程，1/10 active，一共调度1280个线程，完全没有压力。
: 那么对于go来说，得12800个线程才称得上massive parallel。
: 而且最后cooperative threading在latency上拼不拼得过操统线程还
: 不一定。
:
: run
: idle

c*12018-07-13 07:07

21 楼

听上来,Golang用callback function ,不是用thread

run
idle

【在 g****t 的大作中提到】

w*z2018-07-13 07:07

22 楼

中文翻译版
https://mp.weixin.qq.com/s/v-Q5aOnYVj7l-kMQopkPLA

：我这不是描述抽象。是我压根不懂这些技术细节。
：所以只能凭印象说一下。哈哈。原文里面是下面一段。

s*k2018-07-13 07:07

23 楼

Goroutine主要在native thread上做了很细致粒度的，多个goroutine（所谓的G
structure）公用一个thread（M structure）。（具体的狗狗一下）

routine
察到

【在 w**z 的大作中提到】

s*k2018-07-13 07:07

24 楼

http://morsmachine.dk/go-scheduler?spm=a2c5q.11423531.0.0.3d354fa0OblSm4
还是看这个
https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_
kqxDv3I3XMw/edit
还有这个

【在 s********k 的大作中提到】

: Goroutine主要在native thread上做了很细致粒度的，多个goroutine（所谓的G
: structure）公用一个thread（M structure）。（具体的狗狗一下）
:
: routine
: 察到

n*72018-07-13 07:07

25 楼

不错，thx

【在 w**z 的大作中提到】

: 中文翻译版
: https://mp.weixin.qq.com/s/v-Q5aOnYVj7l-kMQopkPLA
:
: ：我这不是描述抽象。是我压根不懂这些技术细节。
: ：所以只能凭印象说一下。哈哈。原文里面是下面一段。

f*t2018-07-13 07:07

26 楼

如果基于运行时记录预测哪个线程应该被执行，是不是能进一步优化性能

w*g2018-07-13 07:07

27 楼

这个对操统线程也适用，而且更一般化。
这种调度能给runtime的overhead极少，
所以预测其实很难做。
我感觉用在磁盘firmware上预测prefetch可能会比较管用。
即使是SSD也比CPU慢的多，预测中了提高会比较明显。

【在 f*******t 的大作中提到】

: 如果基于运行时记录预测哪个线程应该被执行，是不是能进一步优化性能

g*t2018-07-13 07:07

28 楼

你说的很对。

【在 w***g 的大作中提到】

: 这个对操统线程也适用，而且更一般化。
: 这种调度能给runtime的overhead极少，
: 所以预测其实很难做。
: 我感觉用在磁盘firmware上预测prefetch可能会比较管用。
: 即使是SSD也比CPU慢的多，预测中了提高会比较明显。

f*t2018-07-13 07:07

29 楼

我觉得有可能做到。比如100台跑同质服务的分布式系统，挑其中几台做profiling，对
整个系统的性能影响不会很大。分析之后进行预测，通过config的形式部署到其它机器
上，然后再挑机器记录性能的改进和回归，通过A/B testing不断迭代。比如FB几十万
台前端服务器跑的都是一样的PHP代码，每降低0.x%的CPU就能节省以million计的成本。
当然我是从分布式系统角度看这个问题的，不知道单机做这个成本和收益的比例是多少。

【在 w***g 的大作中提到】

g*t2018-07-13 07:07

30 楼

直接deep refeinforcement learning吧。迭代预测的话，你把里面的look up table改
成CNN，那就是deep RL.
多层的表格，好过一层摊开的大表

: 我觉得有可能做到。比如100台跑同质服务的分布式系统，挑其中几台做
profiling，对

: 整个系统的性能影响不会很大。分析之后进行预测，通过config的形式部署到其
它机器

: 上，然后再挑机器记录性能的改进和回归，通过A/B testing不断迭代。比如FB
几十万

: 台前端服务器跑的都是一样的PHP代码，每降低0.x%的CPU就能节省以million计
的成本。

: 当然我是从分布式系统角度看这个问题的，不知道单机做这个成本和收益的比例
是多少。

【在 f*******t 的大作中提到】

: 我觉得有可能做到。比如100台跑同质服务的分布式系统，挑其中几台做profiling，对
: 整个系统的性能影响不会很大。分析之后进行预测，通过config的形式部署到其它机器
: 上，然后再挑机器记录性能的改进和回归，通过A/B testing不断迭代。比如FB几十万
: 台前端服务器跑的都是一样的PHP代码，每降低0.x%的CPU就能节省以million计的成本。
: 当然我是从分布式系统角度看这个问题的，不知道单机做这个成本和收益的比例是多少。

f*t2018-07-13 07:07

31 楼

不一定要deep learning吧，这种东西说不定简单的算一下avg和std就能搞定

【在 g****t 的大作中提到】

: 直接deep refeinforcement learning吧。迭代预测的话，你把里面的look up table改
: 成CNN，那就是deep RL.
: 多层的表格，好过一层摊开的大表
:
:
: 我觉得有可能做到。比如100台跑同质服务的分布式系统，挑其中几台做
: profiling，对
:
: 整个系统的性能影响不会很大。分析之后进行预测，通过config的形式部署到其
: 它机器
:
: 上，然后再挑机器记录性能的改进和回归，通过A/B testing不断迭代。比如FB
: 几十万

g*t2018-07-13 07:07

32 楼

Avg std可能要分段或者滚动计算才行。分段就相当于一层表格。效率可能不如多层表
格，就是DL
之前有过几个文献，本版讨论过。我觉得最新的一些文献的说法有道理。neural
network用折线非线性其实就是查表。那么
多层多表连起来，效率应该是比一层大表好。

: 不一定要deep learning吧，这种东西说不定简单的算一下avg和std就能
搞定

【在 f*******t 的大作中提到】

: 不一定要deep learning吧，这种东西说不定简单的算一下avg和std就能搞定

s*V2018-07-13 07:07

33 楼

听到一种说法，coroutine自愿yield，用一个event loop,　可以处理上百万个用户线
程。

【在 w***g 的大作中提到】

T*i2018-07-13 07:07

34 楼

你才是胡算，同样throughput，cooperative threading 128线程当然拼得过1280操统
线程。同样的latency，throughput恐怕会大一倍。
如果变成12800线程，恐怕就会有数量级的差别了。

【在 w***g 的大作中提到】

w*g2018-07-13 07:07

35 楼

前提是百万个用户线程绝大多数都在等I/O。
用户线程只有在syscall的时候才会yield。如果正在跑的线程
开始算neural network了老也不syscall，别的线程就都会被挂起。
如果就是有这么多并行计算的需求，那么不管用操统线程还是coroutine
都无解。但一般来说，同样的计算任务和硬件，有一个最优线程数。
超过了性能也会下降。
go的套路是鼓励程序员起线程。所以很可能创造出来本来
并不需要的线程。有点没有问题创造问题也要解决的感觉。
写了一大段，说白了，其实最能发挥go的威力的是用go把nginx
重写一遍，能写的更漂亮。未必能比nginx快，但肯定比apache快。
go基本上就是让人能放飞了用epoll kqueue这些东西。
我吐的槽是，虽然牙膏厂挤了这么多年牙膏，CPU算力近十年还是
有显著增长的。和I/O相比，(可用于I/O的)CPU算力应该是更加富余了。
另一方面，和以前用nginx serve静态网页相比，现在的服务器
逻辑更加复杂计算量更加大。相比之下，epoll省下来那点算力
对提高服务器整体吞吐量的作用应该是在降低的。
(注意是epoll和操统线程比剩下来的算力，不是和poll比）
总的来说epoll的重要性本身就在降低。
go我不熟，发帖前在stack overflow验证了下，有错请指正。
Win 3.1的多个程序就是coroutine。到NT/95才有的真正的操统线程。

【在 s*****V 的大作中提到】

: 听到一种说法，coroutine自愿yield，用一个event loop,　可以处理上百万个用户线
: 程。

f*22018-07-13 07:07

36 楼

这个思路我曾经想过，但是问题有一下两点：
1. 大部分情况基本的heuristic可能就够了；
2. 如果RL系统真的理论上better，怎么训练？哪里来的数据？

: 直接deep refeinforcement learning吧。迭代预测的话，你把里面的look up
table改

: 成CNN，那就是deep RL.

: 多层的表格，好过一层摊开的大表

: profiling，对

: 它机器

: 几十万

: 的成本。

: 是多少。

【在 g****t 的大作中提到】

: Avg std可能要分段或者滚动计算才行。分段就相当于一层表格。效率可能不如多层表
: 格，就是DL
: 之前有过几个文献，本版讨论过。我觉得最新的一些文献的说法有道理。neural
: network用折线非线性其实就是查表。那么
: 多层多表连起来，效率应该是比一层大表好。
:
:
: 不一定要deep learning吧，这种东西说不定简单的算一下avg和std就能
: 搞定
:

c*12018-07-13 07:07

37 楼

一般来说.就是这样弄的
#1 用一个event loop
#2 coroutine自愿yield

【在 s*****V 的大作中提到】

: 听到一种说法，coroutine自愿yield，用一个event loop,　可以处理上百万个用户线
: 程。

w*g2018-07-13 07:07

38 楼

你是对的。
我的意思是，现在CPU快，操统调度1280线程也调度的过来。
如果这些线程主要就是等I/O，CPU可能都用不满。优化了也是白优化。
要demonstrate coop thread牛x，得起12800个线程，展示数量级差别才行。

【在 T********i 的大作中提到】

: 你才是胡算，同样throughput，cooperative threading 128线程当然拼得过1280操统
: 线程。同样的latency，throughput恐怕会大一倍。
: 如果变成12800线程，恐怕就会有数量级的差别了。

s*V2018-07-13 07:07

39 楼

大牛太谦虚了，我就是听了一个Rob Pike的talk过来鬼扯两句。这说不定是鸡生蛋，蛋
生鸡的问题，现在牙膏厂不是出28核的cpu了么，单核性能到顶后，多核变成一个趋势
的话，go这种高并发的写法就成了天然的优势。

【在 w***g 的大作中提到】

: 前提是百万个用户线程绝大多数都在等I/O。
: 用户线程只有在syscall的时候才会yield。如果正在跑的线程
: 开始算neural network了老也不syscall，别的线程就都会被挂起。
: 如果就是有这么多并行计算的需求，那么不管用操统线程还是coroutine
: 都无解。但一般来说，同样的计算任务和硬件，有一个最优线程数。
: 超过了性能也会下降。
: go的套路是鼓励程序员起线程。所以很可能创造出来本来
: 并不需要的线程。有点没有问题创造问题也要解决的感觉。
: 写了一大段，说白了，其实最能发挥go的威力的是用go把nginx
: 重写一遍，能写的更漂亮。未必能比nginx快，但肯定比apache快。

f*t2018-07-13 07:07

40 楼

现在Cpu越来越快，memory access可以算io了吗？

【在 w***g 的大作中提到】

: 你是对的。
: 我的意思是，现在CPU快，操统调度1280线程也调度的过来。
: 如果这些线程主要就是等I/O，CPU可能都用不满。优化了也是白优化。
: 要demonstrate coop thread牛x，得起12800个线程，展示数量级差别才行。

g*c2018-07-13 07:07

41 楼

对的，goroutine是green thread，或者叫做user level thread，不是os level
thread。
处理高并发的效率比thread高。
感觉这个是golang在服务器端成功的关键

【在 s********k 的大作中提到】

: Goroutine主要在native thread上做了很细致粒度的，多个goroutine（所谓的G
: structure）公用一个thread（M structure）。（具体的狗狗一下）
:
: routine
: 察到

m*n2018-07-13 07:07

42 楼

听起来很像最近很流行的概念——纤程 coroutine
python3.6升级的重要模组就是async干的和这个差不多吧？

【在 g*c 的大作中提到】

: 对的，goroutine是green thread，或者叫做user level thread，不是os level
: thread。
: 处理高并发的效率比thread高。
: 感觉这个是golang在服务器端成功的关键

g*c2018-07-13 07:07

43 楼

是同一个东西，这个不是最近才流行吧，应该已经流行很久了，毕竟golang 09年诞生
的时候就设计了goroutine了

【在 m*****n 的大作中提到】

: 听起来很像最近很流行的概念——纤程 coroutine
: python3.6升级的重要模组就是async干的和这个差不多吧？