@noqwerty 掩耳盗铃吗 233 ，只要状态页面是绿的我就没问题.jpg

尝试下下面的方法(假设你家里的公网 IP 为 A)：
1. 先确定任意一个能在公司网络环境下能访问的 https 网址，比如 https://www.baidu.com
2. 在公司电脑 host 文件里加入 A 与 1 的网址的对应条目
3. mstsc 里输入 www.baidu.com:33890 访问。

如果能成功的话应该是 rdp 的 tls 握手时被 sni 阻断了。

E3V3 是 4 代 Haswell 架构，无解。强升的话没有巨硬官方支持，出现差错也不好解决。

@BBCCBB #9
> 64 位机器上没要求对象地址必须是 8 的整数倍?
除了一些特别的操作比如 atomic 外，没有强制。但地址对齐对访问内存性能有影响，非对齐地址会导致需要拆分成两次内存访问。在 amd64 下，对于 byte 型数据需要 1 字节对齐，word 需要 2 字节，doubleword 需要 4 字节，quadword 需要 8 字节对齐。

> gc 对象位置在内存里被移动
我看了下 JAVA 的各式 GC 算法里普遍对 young generation 使用 mark-copy 算法，对 old generation 使用 mark-sweep 算法。
你说的移动指的是 copy 过程中的移动吧，Golang 里未采用分代 GC，只有 mark-sweep 。

> 64 位对齐不是说数据的地址是 8 的整数倍吗... 那为啥这里还有 0 和 4 两种结果?

1 楼例子里的 Wg 是 4 字节对齐的，unsafe.Alignof(wg)或 reflect.TypeOf(wg).Align()可以看到。

> 64 位 mac 上执行这个代码多次, 是会出现 0 和 4 两种结果的

wg 分配在栈上，受 runtime 申请栈空间时获得的地址影响，不一定保证 8 字节对齐还是只满足 4 字节对齐。

> 加一个 fmt.Println(wg)使其在堆上分配

加 fmt.Println 让 wg 分配在堆上利用了 tiny allocator 获得的 tiny block 地址在 64 位环境下为 8 字节对齐，
不代表内存分配器一定会给 wg 返回 8 字节对齐的地址，比如下面的代码里 wg 的地址应该只满足 4 字节对齐。

```Go
type Wg struct {

state1 [3]uint32
}

func main() {
var b bool
var wg Wg
fmt.Printf("%p\n", &b)
fmt.Printf("%p\n", &wg)
}
```

@BBCCBB #1 加一个 fmt.Println(wg)使其在堆上分配

CSAPP+APUE+DDIA

这是在黑百度嘛

传统单体应用→聚是一坨屎
拆分成微服务→散是满天稀

非专业前端，这个滚动条应该是有最短长度的吧，否则溢出内容很多的话会不会让滚动条短到肉眼不可见。

应该有特征分析，我开远程 rdp 一直没问题，但之前只要一试 socks 代理就随机丢包。

现代处理器的微架构层面上会将机器指令进一步分解为微指令 micro-ops，根据它们之间是否有 dependency chain 以及 execution unit 限制来决定是否乱序执行。

@ldimple 按照楼上所说 printC 里即使两次不是原子操作，由于先执行的 CAS(sem1, 1, 0)，此时 sema1=0, sema2=1，
应该也不会触发 printB 的条件(sema1=1，sema2=0)吧，为何会走进下面的 printB 逻辑里。

golang 里对 channel 的 range 要等到该 channel 被关闭才会终止。
考虑到 channel 的收发特性一般由 sender 端关闭。

而且我看了下 main 函数里 fileChan 容量只有 5，在工资表 xlsx 文件多于 5 个时
下面的 fileChan <- filePathName 操作像是会一直阻塞。