按理来说这种情况编译器应该有 warning 的，我也没环境无法确定，也可能是用参数忽略掉了这种 warning ，也可能是编译过程有大量 warning 输出大家都不看。如果这版本 gcc 真没有（可能性很小）那建议升级或换 clang 。

贴的第一个代码不对，贴的第二个跟链接里的代码是对的。原因上面 @piaodazhu @C47CH 说了，虽然重复我也说一下。

贴的第一个：
- head 已经在 compare exchange 修改了，不过 new_node 的 next 没设置，导致断了
- 用 compare_exchange_weak 就好，不过我不确定你用的 memory order 对不对
- 这里 length 更新会比实际慢，所以会有差异
- while 里的 old_head = head.load(std::memory_order_release); 除了第一次有用外，没什么用，应该放在 do 上面

贴的第二个，解答你的问题。
如果线程 A 如果执行到 @2 被休眠，如果其他 push 线程 直接执行 @2 ，@3 修改了 head atomic 值，线程 A 不就一直卡死了吗？
不会卡死，因为 compare_exchange_weak 会失败，同时会设置 new_node->next 的值。所以是对的。

4L 你的问题：new_node->next = old_head 放到 while 循环里后逻辑是对的。其它问题参考上面的问题列表

@Symbo1ic
raw 用在能确定指针有效的情况，指针指向对象的生命周期肯定比当前类对象要长，能不用就不用。

其余不用共享的用 unique ，明确表示有所有权。需要所有权转移也用，函数参数返回值等。
（不用转移所有权，但用来延后初始化的场景建议用 optional ）

share_ptr 共享用，随处都用的话得避免循环应用，可以用 weak 解决。有时也用 atomic store load 来做原子操作多线程安全切换里面的对象

内存使用大小上，share 最大，有 custom delete 的 unique 稍微大，没有的 unique 跟 raw 一样
性能上 share 最差，unique 与 raw 接近

收到 bing 通知邮件说可以访问 new Bing 了，不过点开链接，好像跳到一个错误页面后快速跳到老 bing 页面，没有 chatGPT

这三个那里不同？

分着理解吧，unique 就是判断引用计数是不是一，即没有其它 shared ptr 只向同一个对象。

reset 就是指向一个新的对象，原来的引用计数减一可能会释放。


那段代码做的事情就是，如果不是 unique 那就复制一份，保证 p 指向的是 unique 的，做+=操作

@ipwx 多线程情况下修改 shared_ptr 应该是不安全的，建议用 std::atomic_load 与 std::atomic_save 替代修改与读的操作。

我还以为是原子操作 CAS ，是数据库 CAS ？不过都差不多

仅算库存数量场景没问题。有问题的场景是 CAS 的变量相关的东西发生改变。比如你还维护了这十个库存商品的唯一序列号之类的。实际场景下大部分 CAS 的是指针，指针没变但是由于内存分配器又复用了刚释放的位置，新分配的对象还是在一样的指针上，但是对象内容跟之前老的指针完全不一样

在用 type-s ；非常喜欢手感

分母

BLAKE2 算法，支持生成长度 1 ～ 64 字节的结果

提个不新建文件，用原文件格式的方法，核心就是哈希表
把 3M 分成每个桶大小为 3 字节的，1024*1024 个桶；每个桶里用 3 字节保存此电话号码开头在文件中的偏移位置，不过直接存偏移三个字节肯定不够，可以除一个系数存，三个字节够表示 100w+的位置
哈希碰撞问题，首先是选用好的哈希函数，不过 95.37%的密度碰撞出现可能性还是蛮高，具体策略可以再评估各种后再决定，可参考 folly F14 的解决方式，约 12/13=92%来着？

@MageeHuang #10 如果是这种整个页面不用刷新的需求的话，那更好解决，直接开 chrome 浏览器的 dev tools 在 console 里写 javascript 就能解决你的问题。大概需要两句。

var btn = $('这里填写按钮的 selector');
setInterval(()=>btn.click(), 1000);

只有我一个人没看明白楼主想说什么吗？

@exch4nge #8 却是 -> 确实， 紧紧 -> 仅仅；
上面说的两种中，还是 2 好一些，难免遇到 server 卡住，发一部分不给你发剩余的，Proxy 又没有分析 http 响应包不知道包边界在哪。

@exch4nge #5 补充一下，你这个 while True 里面逻辑是严格有顺序的，就是先从 Client 读数据，然后发送到 Server，然后从 Server 等待回应，然后再把回应发到 Client。这种模式在 HTTP 1.1 却是没什么问题，是请求-响应模式。不过，资源大于 64k 的时候，你紧紧把部分资源回应发到 Client，Client 还会等着你发剩余的部分，不会向你这个 Proxy 发送数据，所以你会在那个语句卡住。
1、 要么读写的时候读到数据干为止再转发，
2、要么同时分别处理 C -> S 和 S -> C 两个方向的请求，比如用两个线程（或协程）一个负责从 Client 读数据转发到 Server，另一个负责从 Server 读数据转发到 Client