其实楼主只要想清楚一个问题就行了，http 是依赖 TCP 设计的，你看 http 报文头里面有一个 content-length 实际上就是用来干 沾包 黏包 拆包 这个事情，因为对于 http 服务器来讲，真正的报文协议是一个 http 头 + http body, 但是流式传输 如果没有截断流的机制 就会变成 http 头 + http body + 下一个 http 头的一部分 ，这样解析 tcp 流就会报错，所以 content-length 就是用来干这个事情的。

@neoblackcap #88 一般家用应该都是依赖硬件 NAT 转发，可能真没有为 SCTP 设计过

@neoblackcap #88 那就没毛病了，说白了 就是 IPv4 时代，大部分路由器跟硬件平台 只针对 UDP 跟 TCP 设计了，实际上也就是 UDP 跟 TCP 成为事实标准了

@no1xsyzy #46 关键是 99%的人 IP 以上的东西 就只听说过 TCP UDP，而且大部分路由器也只针对这两个做了 NAT 优化，搞不好你用其它的（我不是很了解 STCP ）,就不兼容了... 好多路由器连 ICMP 都是默认防火墙拦了，而且从私有网到广域网上 层层 NAT，raw IP 协议根本行不通..

因为 TCP 设计就是这样的，而且设计 TCP 的人也只是设计成了流，以至于 TCP 里面有一个 tcp_nodely 的开关，因为小包
用 TCP 发过去不划算（报文头可能比报文本体还大），操作系统要延迟一会看你有没有继续写入，然后凑一起再发出去，但是对于 telnet 这种命令行，你延迟发过去，远程操作服务器的人就有延迟，人用起来就不爽了。

TCP 流式传输本质上并没有解决上层应用程序员的问题，程序员要的是 类似 HTTP Websocket 这种一问一答的设计，而且这种设计的可靠性由底层来维护，上层的应用逻辑不需要写代码来尽可能维护这个数据传输可靠性，但是除了 TCP 一个能打都没有，你就只能用 UDP，但 UDP 既不保证 包的顺序，也不保证包一定送到，还得写一大堆逻辑去维护会话状态，所以大家纷纷用 TCP 来做可靠性，像 HTTP 里面 实际上就是浏览器用 HTTP 头告诉 http 服务器，我剩下的 body 内容有多少，服务器兄弟你慢慢读，读完这么多就算是我一个 http 请求的包，服务器兄弟你千万别搞混球了把下一个 http 的报文头 一起当一个 http 包给解析了。

@xuweifeng1987 #41

人家都把屎糊在你脸上了，还在这里谈人脉，你也要分什么情况，核心员工平时都是老板的心头肉，吃肉都不会少的，
楼主这一打工的，你也跟人家谈人脉，怕不是搞笑。

@ezksdo #45
你要 A 线程 写了 volatile，另外一个 B 线程 后续去读 volatile，保障 B 线程能观测到 A 线程写 volatile 之前的事情都发生，这才算是 happen before

你要 A 线程 写了 volatile，另外一个 B 线程 后续去读 volatile，保障 B 线程能观测到 A 线程写 volatile 之前的事情都发生，这才算是 happen before

@ezksdo #45 你要 A 线程 写了 volatile，另外一个 B 线程 后续去读 volatile，保障 B 线程能观测到 A 线程写 volatile 的事情都发生，这才算是 happen before

@ezksdo #45 如果读写 volatie.. 都是在同一个线程里面， 又何来一个线程 对 另外一个线程 观测到的 happen before ?

@ezksdo #41 关键是我那个死循环的地方 你有留意看了没有，跟激进编译半毛钱关系都没有

https://ww1.sinaimg.cn/large/005DO33Hgy1gmxpejwhamj31uw0nmn4o.jpg

第一步要通过 R15 寄存器 偏移 0x108 的位置去取值，

第二步才是跟存放了 立即值 0 的 RAX 寄存器比较

比较失败跳回第一步 ，这跟 JVM 激进优化有半毛钱关系？ 分明就是 [R15 + 0x108] 寄存器的指针 取不到新的值

@ezksdo #41

https://www.zhihu.com/question/263528143/answer/270308453

而且你从这个原答案里面可以看到
lock addl $0x0, (%rsp); 对 rsp 指针 + 0 操作是毫无意义的，rsp 是栈顶指针
lock 是让 cache 失效，保证可见性，如果可见性没有保证，代码依旧会死循环

而对 变量 i 加 volatile 属性 并没有使用 happen before