@guanhui07 除了 #82 里说的，其他还有很多，go 并发编程里随便弄些协程做常驻任务运行，还可以方便结合 chan 、mutex 之类的实现各种功能，我搜的 swoole 例子里主要是 http handler 处理 http 请求这种，更广泛的业务场景怕是差距更大，不只是简单的无状态接口这个地方的协程的便利性

@Frankcox #56

我也没有说是协程执行先后顺序的问题呀。。
可能我给那几个步骤排序，造成了你的误解、误以为我在说协程执行的先后顺序。
请仔细看下，我说的是不同协程里，golang 对 chan 的操作时序保证，这与 go f()是否被先调度执行是无关的

> OP 的疑问是如何确保如果两个协程在不同的 core 上执行，修改的值在不同的 core cache 上同步

不管你是单核心并发、还是多核心并发或并行，chan 都在语言层面通过锁、调度器做了这个对并发操作 chan 行为的顺序保证，就是官网里这句：A receive from an unbuffered channel is synchronized before the completion of the corresponding send on that channel.

所以 OP 把问题本身就搞混了

官网里这个例子前面那句写的很清楚了：
> A receive from an unbuffered channel is synchronized before the completion of the corresponding send on that channel.
> 无缓冲的 chan 的接收在该 chan 上相应的发送完成之前进行同步。

如果没有这个保证，c <- 0 可能先于 f()协程完成、所以很可能 a 还没被设置。
但有了这个保证，则例子中：
<-c 先于 c <- 0 完成;
a = "hello, world" 先于 <-c ，所以也先于 c <- 0;
print(a) 在 c <- 0 之后，所以 a = "hello, world" 先于 print(a)，所以肯定打印了 hello world 。


本质上 OP 是迷惑为什么“无缓冲的 chan 的接收在该 chan 上相应的发送完成之前进行同步”。
这个可以自己啃下 runtime/chan.go 源码

完全没毛病，人家出钱了啊

@guanhui07 #81

看了下，看样子 swoole 确实是框架内置了一些驱动已经与协程结合起来了，例如 mysql 、redis ，确实很不错。
但这毕竟仍然是框架级的，也就是说，必须得 swoole 框架支持慢 IO 操作才能真正实现同步代码底层非阻塞+自动调度。三方的东西很多，如果需要依赖一些 swoole 尚未支持的，则仍然是可能阻塞的。
golang 是语言级支持了这些，三方的 golang 驱动实现基于 golang 标准库即可获得同步代码底层非阻塞+自动调度。

所以也不能完全说“没什么不同”

艺福堂口粮龙井，滇红经典 58

看 OP 的需求应该是想 database 隔离、但是怕连接池数量太大吧，如果是这样、好像可以用同一组连接池，语句里指定 database 更好些吧，比如 select * from database.table ，但可能已有代码要改动很多

@xbchaonba #33 好嘞！欢迎使用，如果有疑问、bug ，也欢迎来 issue 、PR

@xbchaonba #30

> conn.SetReadDeadline(time.Now().Add(time.Second / 120)) 是要用这个方法更新吧

是用这个方法。
但你这个是 120 分之一秒，设置完后很快就过期了，如果没有立刻收到新消息，就 close 了

> 昨天试了好多次 u.KeepaliveTime = time.Second / 120 直接这样重新赋值没有用

同样的问题，估计也是因为 120 分之一秒太快了

@shermie #75

还有一个问题，你说的这个 PHP 协程，不管需不需要 yield ，会不会在使用系统调用、其他慢 IO 时阻塞了，因为已有的很多系统调用、慢 IO ，比如网络 IO 、操作数据库，如果这些底层接口并没有自动出让线程，那跟我前面提到的 Java 虚拟线程可能会是类似的问题。当你处理这些的时候如果阻塞了、线程就在那等待了，不能充分利用 CPU 、不是协程那种真的并发。我只是猜测、我并不了解你说的这个 PHP 协程哈

@xbchaonba #27

dev 修改了下，默认会开启读超时的更新，可以试下：
go get -u github.com/lesismal/nbio@a81e8e2

过阵子再发到新版

@GCP #26

椅子这种还是得试坐，而且最好不只是简单试坐一会，至少模拟办公之类的坐上个把小时才好体验出来。否则八成都是人体不工学。
而且再怎么舒服、它也是久坐，解决不了根本问题，频繁起来走动、运动比任何椅子都强，而且可以治疗、康复颈肩腰痛。

@xbchaonba #27

为了避免僵尸连接耗尽 server 资源，尤其是进电梯导致信号终断、移动信号切换信号塔、设备掉电等情况时，收不到 TCP 协议的 FIN ，连接一直无法退出。TCP 设置 keepalive 是检测四层链路健康，可以避免这种情况，但它并不能解决七层僵尸连接、慢连接的问题，因为四层链路可能一直是健康的，但这个连接什么数据都不发或者只发很少数据、仍然会耗尽 server 资源，所以七层的 keepalive 是需要的，有了七层、再做四层的 TCP 设置 keepalive 就画蛇添足了、没必要。既然应该做七层，所以就应该都设置读超时比较好，所以与其他很多框架默认不设置读超时不太一样，nbio 默认设置。

一直有发数据仍然断开是因为 Upgrade 过程中默认设置了 120s 读超时，但后续收到消息时没有自动更新读超时。
当前版本，server 端设置 upgrader.KeepaliveTime = YourKeepaliveDuration 即可自动更新读超时，设置 upgrader.KeepaliveTime = YourKeepaliveDuration 后，不只是 PING 、其他类型的 message 也都可以，因为是读到消息就更新超时。僵尸连接检测也不是必须要 PING 协议才行、有效的协议即可。
我考虑下，要不要把这个心跳间隔也做成默认配置、自动更新读超时。

如果不想设置读超时，可以在 Upgrade 后 SetReadDeadline(time.Time{}) 清空超时关闭。

燃风宁芝解君忧

网易严选名字起得挺好，但产品真没见过几个好的

要么买米勒，要么必须现场多试几次并且最好坐多一会再确定。否则，95 成的人体工学椅，其实都是人体不工学

@shermie #47

我搜了下，PHP 也有协程，所以我猜你是指 PHP 协程？
如果是这样，那我补充一点，除了 erlang 、golang ，多年前 lua 或者 c/cpp 也早就有协程或者库，但都是手动挡，比如 lua 的 yield resume ，我刚才搜的帖子里 PHP 的方式也是需要手动 yield 。
近几年 js py 之类的也搞了 async await 这些。确实，整体看上去是同步代码、顺序可读了。但是，这种手动挡理解起来并不直观，对于步骤层次不多的，个人觉得手动挡协程甚至不如 callback 。
nodejs 还有 Promise 这种，看上去是那个顺序，但并发的时序可能不是那个顺序，很多人因为这个写 bug 、或者理解吃力、或者要自己控制时序时非常麻烦。

很多人可能没有深度使用 erlang 、golang 协程，或者已经习惯了那些手动挡的蹩脚协程，所以 get 不到 erlang 、golang 这种像线程一样的并发有多爽。

Java 的虚拟线程还是啥也是类似协程，但似乎只是解决了语言指令级的调度，系统调用等行为并不会主动出让并可能因为阻塞占用了线程，我没有深入研究、不知道是否理解有误，但好像 Java 至少仍然需要解决大量的底层接口与虚拟线程调度结合的问题，这仍然需要很大的改造。

再补充一些，现实业务不只是 CURD ，PHP 的编程姿势主要是为 Web 服务，一旦有复杂的需求，用 PHP 实现起来会很蹩脚、或者浪费资源，比如游戏

#2 > php 很多业务场景 go 开发起来是无法胜任的

所以我觉得，你这个可能把现象搞错了。现象是 PHP 有众多轮子，并且未必需要高性能或者什么，用 go 去重新做成本收益不划算。就像好些人说企业级只能 Java 一样，其实不是 golang 或者其他不能搞，而是因为 Java 已经形成了成熟的产业链和社区，并且企业级的业务 Java 性能各方面也足够胜任。用 golang 或者其他语言去重造需要很长时间，而现实商业场景，没哪家资本愿意去推动这个。但如果是新团队重新造这些，是可以用 golang 的。字节系大量业务用 golang ，飞书应该也用得挺多的，人家有钱有资源有人才，就是可以搞。
除了极度性能场景是 c/cpp/rust 的天下，或者特殊专用领域，绝大部分的通用领域、绝大部分高并发高性能场景，golang 能搞、PHP 却未必能胜任。

@lifei6671 #25

你们的运维兄弟是懂怎么挣钱的。。。

最近好几次看到有人说脚本语言 ORM 牛逼，强类型语言 ORM 垃圾。

保持清醒一点好吗？弱类型 ORM 当然轻松了，但是你失去的是编译期检查，失去的是强类型系统规范安全保障等一系列优势。
ORM 只是让你获得了舒适区，就像刷抖音，很舒服，你获得了一些东西：比如你不太需要去思考 sql 语句如何写出来。但是你同时也大大减少了对不同数据集合处理的思考。如果是大表大数据集合，往往都是性能相关、对业务性命攸关的。当你习惯了只要 ORM 能实现业务逻辑的时候，扪心自问、有能力配得上去做海量业务海量数据的业务吗？随便一个 API 里的 ORM 生成的 sql 就可能把数据库卡住导致大量业务请求失败！
按照金字塔模型，这种层次的 CURDer 是开发者的主力群体，任何一个人保持在这个水平层次上都没问题，因为并不是每个人都需要去对高并发高性能这件事情负责，多数商业场景，随便写写都可以搞定。但是，如果是自己安于停留在这个层次，就不要出来拿性能说事、标榜我 PHP 或者我 Java 或者我什么语言很强了。或者如果自己想提升自己的技术境界技术能力，就不要把着眼前这点脚本语言的简单性能测试或者什么来对比了，参考我上一条回复，咱也不吹谷歌 golang 团队那两外老爷子和其他年轻一代的众神、因为其他语言的作者团队们也都是众神，但各个大厂的技术管理层跟进什么放弃什么是很有参考价值的、因为他们直面的就是工程领域商业战场，他们可不是傻子。

PS：我自己写 golang ，我也仍然经常说 golang 性能怎么也无法赶上 c/cpp/rust ，因为我也写 c/cpp ，我淘空了心思优化 golang 也仍然赶不上 c/cpp

建议 OP 多想想吧，那么多大厂跟进 golang ，人家的 CTO 、技术管理层，哪个不是背景闪耀、身经百战，哪个不是血雨腥风海量业务里杀出来的？你以为这些技术领头羊们都是弱智都是吃素的嘛。。。

另一个侧面，阿里当年从 LAMP 转型，放弃 PHP 到 Java 的时候跟 golang 也没关系，如果 PHP 给力还需要还 Java 吗？

别说什么 PHP 现在性能也提升了，语言指令性能的提升并不是性能的全部，只是一部分，甚至只是一小部分。
能写同步代码的编程语言，HTTP 服务的性能瓶颈多数时候都是慢 IO 占用系统线程。
能写异步代码的编程语言，又要面对 callback hell ，比如传统的 c/c++，脚本里 nodejs 。
简单 CURD 你不需要 RPC 、不需要各种基础设施的慢 IO 操作、你的 API 通常也不是海量并发，这时候一切看上去都还很美好，因为你搞定了业务、性能指标也并不比其他语言差，开发效率贼高，心里贼爽。
但是，如果接口里需要这些同步代码进行慢 IO 操作、并且会导致直接阻塞了线程，又遇到海量业务场景高并发的时候，系统线程数量瓶颈、并发度有限、会导致几何级的响应性能降级、请求积压，这时候如果跟那些异步非阻塞语言相比（ golang 这种同步代码但底层 runtime 实际上是异步非阻塞、不需要因为系统线程数量为 N 就只能并发处理 N 个请求，本质上也是异步非阻塞，但让用户可以写同步代码），差距就下来了。
所以别被那些语言指令性能的 benchmark 灌醉。

语言慢 IO 占用系统线程不只是 PHP ，Java 非 Netty ，或者 Java Netty+同步方式操作慢 IO 基础设施之类的，或者其他语言类似的方式，也同样有这些瓶颈。