之前已升级的，联系客服回退，答复:

Google Workspace Support, Aldwin: Fantastic! Thank you for choosing! I’ve noted that you are interested in an alternative Workspace experience at no cost. You can continue to enjoy your Google Workspace edition for no cost. You will not be billed for your Google Workspace account for the foreseeable future. No further action is needed at this time.

可是刷新 Admin 的订阅页面还是有付费时间表的，再等等看吧~

坑了，已升级还能回退吗

@geekvcn 哈哈，确实不是非常清楚 TSO/GSO 的实现细节，结合平时的使用感受(我的 r8169 网卡不支持 TSO)就“推测”了一把，好在被及时指正了 :P

nanopi-m4 + usb3 硬盘盒 + btrfs + nginx-webdav/sftp

@geeglo 感谢 @FabricPath 前面说法被证伪了，刚才查了一下资料也做了一下实验，开启 TSO 或 TSO 时，在 netfilter 确实是合并后的大 skb 。

@geeglo 有结论来分享一下哈，把推测证实或证伪，细节具体化，感谢~

@geeglo iptables 可以过滤到 tcp 流中每一个具体的 packet 的转发与否，所以可推测这种情况下在与网卡的交互上没有启用相关的硬件加速技术。记得之前在有些光猫上使用 iptables 实现某些操作还需要关闭硬件加速，否则根本走不到 iptables 的路径上。

具体情况具体对待吧，利用好硬件加速会更香。

@geeglo
@ryd994

我理解当有网卡加速来处理 tcp stream 与 iptables 处理 raw packet 的区别，借用快递类似的话，接收：raw packet 是能一次运送(DMA)很多个 packet ，且每个 packet 都带有收发人地址，快递员到达时按一下门铃(中断)让接收人（ CPU ）处理，CPU 需要修改每个 packet 上的收发人地址。而 tcp stream 的话，网卡收到若干个 raw packet ，将同一个 tcp stream 的 packet 在网卡上合并成一个较大的 packet ，大 packet 只带有一个收发人地址(因为同 stream 都相同)，通知 CPU 处理，CPU 只需改一次收发人地址即可。在内核态、用户态交互上，只要 buffer 不大小，上下文切换的次数也是比较少的。

从转发节点内部来看，用户态转发比 iptables 肯定包括了更多的上下文切换以及可能更多的 copy 开销。用户态转发是两条 tcp stream ，且有缓冲； iptables 转发是 raw packet 转发；考虑到网络延迟及对流控的影响，转发节点内部开销不一定是决定性因素。

{ dpdk, raw socket packet mmap, xdp } + busyloop

@revlis7 那就说明肯定是啦，这事就有意思了

就在此时此刻做个不加 @vip1 后辍的对比呀

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(也可专门开个复位线程来干)。这种要硬件乱序才能出问题的测试，很少次数就靠运气，但只要在弱内存序架构上多跑一会肯定会有的。