这个不是多线程的 bug ，这个是 C/C++编译器的"特性"。
相当于有这样一段代码：
```c++
int flag;

while (flag == 0) {
}
```
编译器在不进行优化(-O0)的情况下，每次 while 循环都会从内存中读 flag 的值，并和 0 进行判断。
当使用了编译器优化的情况下，编译器就会发现"这个程序员真 SB ，为什么每次都要从内存中读 flag 的值呢，我直接读一次，放到寄存器里面，之后访问速度就更快了，判断也可以优化成一次"，于是代码就变成这样了：
```c++
register eax = flag;
if (eax == 0) {
while (true) {
}
}
```
你会发现这个优化在单线程的情况下是完全没有问题的，在多线程情况下就出问题了。
而使用 volatile int flag 就是告诉编译器"不要偷懒，我让你从内存读 flag 你就从内存读，让你写到内存就写到内存"。

不过如上面所说，建议多线程通信使用 atomic ，因为 atomic 还解决了多线程情况下的内存序的问题。

@wwzgxsyf #33 是的，点击生成的图片就全屏放大预览

哈哈我前两天还用了这个小程序，生成效果挺好的，不过吐槽一下生成的图片不能放大只能直接保存相册，体验不太好。另外问下这个也是用 GPT 4o 做的吗？

因为++运算符会修改 d 的值，而((char*)d)看起来被识别为了右值，只能读不能修改，所以就报错了。
1 楼的换成+1 没问题是因为+1 不会修改值，所以((char*)d)被被识别为了右值也没问题。
value2 那里没有出问题我猜是先计算了++运算，表达式变成了这样：*( (char*)(d++) )

@bthulu #15 纯 tcp 协议我接触得不多，你可以试试在 server 上多监听几个端口，或者问问 ChatGPT 看能不能调整一些系统参数

@bthulu #11 nginx 反向代理也会启用长连接

@bthulu 另外同一个 TCP 连接在完成一个请求之后可以不断开继续完成下一个请求(也叫长连接)，如果单个请求很简单(比如发送 index.html)的话，是可以在短时间内完成多次请求的。一般 http 压力测试的话都会启用长连接，因为长连接更考验 nginx 的性能，如果每次都新建 TCP 连接的话考验的是操作系统和 TCP 协议的性能

@bthulu 比如 nginx 监听 443 端口，IP 是 1.1.1.1 ，一个 client 的 IP 是 2.2.2.2 ，那么这个 client 理论上可以向 nginx 建立 65535 个连接，每个连接的四元组在 client 上看是(src ip = 2.2.2.2, src port=1 到 65535 ，dst ip=1.1.1.1, dst port = 443)，在 nginx 上看的话 src 和 dst 会交换。但是如果有另一个 client 的 IP 是 3.3.3.3 ，那么又可以和 nginx 建立 65535 个连接，这样 nginx 就可以同时服务 65535*2 个连接，这些连接的四元组是不同的，所以不会出问题。

我好像不能放图，代码基本上是这样的：

```
r = requests.get('http://182.61.200.7', headers={'Host': 'www.baidu.com'})
r.encoding = 'utf-8'
print(r.text)
```

我用 wireshark 抓包，发送的 HTTP 请求中的 Host 字段被正确修改为了 www.baidu.com 。
我的测试环境是 Ubuntu，Python 3.6.9 。

我把 IP 地址换成 182.61.200.7，楼主的代码就能正常访问了。

@ch2 我测试没有问题，可以使用 headers 覆盖 Host

我倒是好奇为什么会裁员，有说甲骨文中国依然在盈利，所以不明白裁员的缘由。

应该是异步数据加载的关系吧，你可以试试打开关键页面之后，等待几秒钟再获取 page_resource

@myyou 毕竟内存回收是需要消耗算力的，而且 go 的内存回收还会暂停主程序，所以在内存充足的时候可以不进行内存回收。如果想要测试内存回收，你可以写一个函数，函数内部不断申请内存，然后在主函数不断调用该函数，看看程序的内存会不会无限增长。

go 和 java 的内存回收都不是实时进行的

厉害

@xiangyuecn #130 涨姿势了

@xiangyuecn #76 我没怎么接触过 chrome 扩展，不知道怎么实现“能够在 ui 界面展示昵称，但是应用提供商不能获取用户的昵称”功能