@BeautifulSoap
@xiaxiaocao
@codehz

首先非常感谢各位大佬的回答，因为我平时高并发做得比较少，所以这块知识有点混乱，再加上表达能力确实不太好，导致挺多人 Get 不到我疑惑的地方。

然后对于 @BeautifulSoap ：
1. 因为单线程程序没有并发可见性问题，所以我就先假设了两个协程分别跑在不同的 CPU 核心上
2. 谢谢你分享的这篇文章，纠正了我的一个误区：之前我以为 happens-before 规则只是一个事件发生顺序的一个规定，但其实它还包含了”可见性“的语义，A happens-before B 代表 A 对共享变量做出的修改，对于 B 来说是可见的。

然后 golang 的 channel 为了满足可见性要求，我猜底层应该会有以下操作：
1. 线程 A 修改共享变量，不能只将修改保存在线程所在 CPU 核心的缓存里，还要将它同步回内存
2. 如果其它 CPU 核心上也有此共享变量，需要将缓存里的变量设置为失效状态
3. 其它核心上的线程读取共享变量，因为所在核心的缓存状态已标记为失效，只能去内存里读，此时就能读到最新的变量值了

我这样理解对不对呢？

@raynor2011
@cyrivlclth

非常感谢，我先消化下你们发出来的链接内容

@ZField #28 对，java 的 volatile 关键字，我看网上资料说是通过禁用 CPU 缓存来解决可见性问题的，但 golang 的 channel 是不是通过同样的方式去解决的就不知道了，还是说可见性问题只存在 java ？但这个貌似也说不通，只要是多线程并发，应该就会有可见性问题

@cyrivlclth #21 所以可见性问题只存在于 Java 语言吗

@yph007595 #15 因为 CPU 有多个核心，每个核心都有独立的缓存，线程 A 修改了共享变量，那么这个修改只会存储到它自己所在的核心，跑在其它 CPU 核心的线程不一定能知道这个修改，比如 java 语言提供的 volatile 关键字，就是通过禁用 CPU 缓存来解决这个可见性问题的（最后一句关于 java 的话来自 ChatGPT ）

@InDom 谢谢回答，我知道无缓冲的 channel 会阻塞，但我关注的重点是多线程并发的可见性问题，具体可以看 #5 的回复

@sunny352787 可是就算 channel 阻塞结束了，main 协程也不一定能够打印出 "hello, world" 吧？因为 golang 是多线程，多线程并发就会有可见性问题，一个线程修改了共享变量，这个修改对于其它线程来说不一定能观测到

9 年经验 6k ？

@brader 回复 2 楼，其实现实中微信聊天，对方一般也是等全部内容输入完了才会发给你的，所以换到 chatgpt ，等全部内容接收完后，做一次检测再发送给用户这个我觉得问题不大。关键点是你要提醒用户你正在打字，比如“程序正在生成回答，已经生成了 xx 个字，请耐心等待”，总之就是不要让用户觉得你的程序卡住了

简单问题复杂化了，请求失败就 sleep 1 秒或 2 秒，然后重试就可以了

不能拿上海来比的，上海是超一线城市，去什么样的城市打工就要有什么样的工资预期

@ffffb 作为一个在广州的码农，看到你没提到广州，突然有点失落😂

@q447643445 回复#106 ，不是跟工资挂钩，是跟失业保险的缴纳基数挂钩

macbook 和 win 本都有在用，个人认为 macbook 最好用的是它的触摸板和多指触控手势，目前还没遇到过触摸板体验可以跟 macbook 媲美的 win 本，我用 win 本都会习惯配一个鼠标，还有 macbook 的屏幕和喇叭音质也极好，然后其它方面在使用感受上差距不大

这些 receipt-data 背后的购买物品是什么类型的？消耗型的还是订阅型的？

@iamzuoxinyu 感谢回答，那其实就是，协程调度器和 epoll 并不是两个完全不相关的技术，协程调度器也是基于 epoll 来实现的，只是 epoll 是更加底层的技术

这厚度，而且没有掌托，敲代码肯定会很累

调用苹果的收据验证(verifyReceipt)接口时，要注意判断 in_app 字段，这个数组字段有可能会是空的，这种情况不要给用户发货

2k ？认真的吗