2606:4700:00f4:: 46.1 ms
2606:4700:83b0:: 44.1 ms
2606:4700:90c0:: 45.1 ms
2606:4700:90d0:: 48.6 ms
2606:4700:91b0:: 45.4 ms
2606:4700:9640:: 44.3 ms
2606:4700:9760:: 42.7 ms
2606:4700:99e0:: 41.2 ms
2606:4700:9a90:: 43.5 ms
2606:4700:9ad0:: 44.0 ms
2606:4700:9ae0:: 46.2 ms
2606:4700:9b00:: 44.7 ms
2606:4700:9c60:: 44.8 ms

@fengchen0vr 确实需要一些配置哈，ipv6 是直连的。

@Suddoo #11 针对不要机理能跑就行的，我说了语法糖甜。针对需要机理的，我也说了展开的实现相对更容易了解。我能感受到你这段话的本意，但基本道理上并没有错。

@Suddoo 语法糖就是甜呀，哈哈，但也更难看清背后机理了（要啥机理，能跑就行 :P ）。他这不仅是 Singleton 还要 Lazy Initialization 。

@JasonLaw 其实用 final 修饰最好，对于写端包含 final 字段的对象都是安全初始化的，也就是说对象成员字段在初始化时的赋值 store 一定在对象地址写入引用变量的 store 前可见。对于读端 final
instance 可以按常量来优化。

愉快的 IPv4/IPv6+TCP/UDP(over TCP): https://github.com/heiher/hev-socks5-tproxy

我觉得你想优化掉 instance 的 volatile 减少非首次 getInstance 的开销，有个办法但要浪费点空间：

```java
public class DclSingleton {
private static DclSingleton instance;
private static volatile DclSingleton _instance;
public static DclSingleton getInstance() {
if (instance == null) {
synchronized (DclSingleton .class) {
if (instance == null) {
_instance = new DclSingleton();
instance = _instance;
}
}
}
return instance;
}

// private constructor and other methods...
}
```

记得也有 API 可以直接插入内存屏障，如果可以更好。

不加 volatile ，就可能发生 DclSingleton 对象的 filed 初始化赋值的 store 与 instance 的赋值的 store 乱序。测试逻辑就基于这个情况检测就行了，DclSingletion 增加 field 在构建函数中赋值，启动一批线程跑 getInstance 保存在局部变量，当获得的 instance 非空时，读 field 判断是否为有效赋值，最后再将 instance 复位为 null(也可专门开个复位线程来干)。这种要硬件乱序才能出问题的测试，很少次数就靠运气，但只要在弱内存序架构上多跑一会肯定会有的。

@chanlk 示例 2 不管是 writer 还是 reader 先执行，只要 flag==true ，则 i 必然==42 吧。因为 flag 是 volatile 变量，不仅限制了编译器代码生成上其它变量访存与 flag 访存的重排，在弱内存一致性架构上还会插入内存屏障指令阻止硬件执行时的乱序。

这种感觉是应该是路由侧问题吧，试过换个路由或用 PC 拨号测测吗？

各位使用 wireguard ，udp 限流不严重吗？

@cathiabi 没有超管就用 vlan 交换机把光猫互联网和 itv 口各自连到交换机并配置两个 vlan 。

想起了在用的 DIY 方案： https://hev.cc/2928.html

一切皆是对象~

不错，不错，前段时间问过苏州移动的，只有专线能给固定 ipv4 ，记得同等速率月价格差不多是这年价。

有没有 ipv6 呀？

这哪里呀，1080 就有固定 ip ，关键还是年呀

@amiwrong123 需要防止 Store interested[process] 乱序到 Load turn 之后：

interested[process] = TRUE;
turn = process;
storeload_barrier (mfence on x86)
while (turn == process && interested[other] == TRUE);

刚执行过 turn = self_process ，随后的判断 turn == self_process 就不成立，则说明一定有其它进程也执行了 turn = process ，但也一定会卡在 interested[other] == true 条件上，所以当前线程可以安全进入临界区。另外，挺有意思的是这个算法在 x86 的内存模型上需要使用内存屏障指令。

再补充一点，store buffer 和 cache invalidate queue 也是产生访存乱序效果的因素之一，这两导致访存乱序效果是可以在读端和写端都按序执行的情况下。

即使是单核 CPU 也可乱序执行，乱序执行能提高多部件利用效率，避免资源访问延迟产生的空等等等，cache 一致性维护开销产生的延迟当然也是一个因素之一，但并非全部。只是并行的多核（多读端）能观察到乱序而已。