在Understanding Real-World Concurrency Bugs in Go这篇论文中，几名研究人员分析了常见的Go并发bug，并在最流行的几个Go开源项目中进行了验证。本文梳理了论文中提到的常见的bug并给出解决方法的分析。 论文中对bugs进行了分类，分为阻塞式和非阻塞式两种： 阻塞式：goroutine发生阻塞无法继续执行（例如死锁） 非阻塞式：不会阻塞执行，但存在潜在的数据冲突（例如并发写） 阻塞式bug 阻塞式bug发生的根因有两种，一种是共享内存（例如卡在了意图保护共享内存的锁操作上），一种是消息传递（比如等待chan）。同时研究发现共享内存和消息传递导致的bug数量不想上下，但是共享这种方法的使用量比消息传递使用的更频繁，所以也得出了共享内存方式更不容易导致bug的结论。 读写锁优先级导致的死锁 在Go中的写锁优先级高于读锁优先级，假设一个goroutine（goroutine A）连续获取两次读锁，而另一个goroutine（goroutine B）在gouroutine A两次获取读锁中间获取了写锁，就会导致死锁的发生。论文中没有针对这个bug给出示例代码，我写了一个简单的代码示意一下。 func gouroutine1() { m.RLock() m.RLock() } func gouroutine2() { m.WLock() } f1和f2都在goroutine中执行，当f1执行完第一个l.RLock()语句后，假设这时f2的m.WLock执行，由于写锁是排它的，WLock本身被f1的第一个m.RLock()阻塞，写锁操作本身又会阻塞f1中的第二个m.RLock WaitGroup误用导致的死锁 这种情况就是比较典型的WaitGroup的误用了，提前执行group.Wait()会导致部分group.Done()无法执行到，进而导致程序被阻塞。 var group sync.WaitGroup group.Add(len(pm.plugins)) for _, p := range pm.plugins { go func(p *plugin) { defer group.Done() } group.Wait() // blocked } // group.Wait() should be here for循环内的group.Wait()执行到的时候，循环内的部分goroutine还没有被创建出来，其中的group.Done()也就永远没法执行到，所以会导致永远阻塞在这一句，正确的写法是将group.Wait()移到for循环外。 Channel的误用 Channel是go支持并发的一个非常重要的特性，Channel虽然在很多场景下非常解决问题，但是误用也是不容易发现的。 func goroutine1() { m.Lock() ch <- request // blocked m.Unlock() } func goroutine2() { for { m.Lock() // 阻塞 m.Unlock() request <- ch } } 这段代码的业务语义是goroutine1会通过ch接收goroutine2发送的消息，但是当goroutine1执行到ch <- request时候会阻塞并等待ch，此时由于goroutine1没有释放锁，goroutine2的m.Lock()也会阻塞，形成死锁。 ...

一个偶然的机会，发现一条 SQL 语句在不同的 MySQL 实例上执行得到了不同的结果。 问题描述 创建商品表 product_tbl 和商品操作记录表 product_operation_tbl 两个表，来模拟下业务场景，结构和数据如下： 接下来需要查询所有商品最新的修改时间，使用如下语句： select t1.id, t1.name, t2.product_id, t2.created_at from product_tbl t1 left join (select * from product_operation_log_tbl order by created_at desc) t2 on t1.id = t2.product_id group by t1.id; 通过结果可以看到，子查询先将 product_operation_log_tbl 里的所有记录按创建时间(created_at)逆序，然后和 product_tbl 进行 join 操作，进而查询出的商品的最新修改时间。 在区域 A 的 MySQL 实例上，查询商品最新修改时间可以得到正确结果，但是在区域 B 的 MySQL 实例上，得到的修改时间并不是最新的，而是最老的。通过对语句进行简化，发现是子查询中的 order by created_at desc 语句在区域 B 的实例上没有生效。 排查过程 难道区域会影响 MySQL 的行为？经过 DBA 排查，区域 A 的 MySQL 是 5.6 版，区域 B 的 MySQL 是 5.7 版，并且找到了这篇文章： ...

在 WSL2 环境中 clone 一个很大的 git 项目，不走代理速度很慢，所以研究了一下怎么让 WSL2 走 Windows 的代理客户端。 WSL1 和 WSL2 网络的区别 在 WSL1 时代，由于 Linux 子系统和 Windows 共享了网络端口，所以访问 Windows 的代理非常简单。例如 Windows 的代理客户端监听了 8000 端口，那么只需要在 Linux 子系统中执行如下命令，就可以让当前 session 中的请求通过代理访问互联网。 export ALL_PROXY="http://127.0.0.1:8000" 但是 WSL2 基于 Hyper-V 运行，导致 Linux 子系统和 Windows 在网络上是两台各自独立的机器，从 Linux 子系统访问 Windows 首先需要找到 Windows 的 IP。 配置 WSL2 访问 Windows 上的代理 有两个关键步骤： WSL2 中配置的代理要指向 Windows 的 IP； Windows 上的代理客户端需要允许来自本地局域网的请求； 由于 Linux 子系统也是通过 Windows 访问网络，所以 Linux 子系统中的网关指向的是 Windows，DNS 服务器指向的也是 Windows，基于这两个特性，我们可以将 Windows 的 IP 读取出来。 ...

为什么要使用 Windows 做开发 一直以来 macOS 以类 unix 的特性，获得了程序员的青睐，但是近几年 Apple 在硬件领域少有让人耳目一新的产品，加上取消 Esc、使用蝶式键盘、基本为 0 的硬件可升级性、系统权限的收紧等骚操作，让 Mac 从软件到硬件都不如以前适合编程。另一方面，PC 阵营在软件层面保持开放的基础上，硬件体验也逐步赶上甚至超越 Mac，我也不想在用 Mac 做开发，用 PC 玩游戏，希望用一台电脑兼顾游戏和开发，所以选择回到了 PC 阵营。 随着微软拥抱开源领域，Windows 也开始变得程序员友好。Windows 10 2004 发布后，WSL2 也可以在正式版 Windows 10 中使用，相比于 macOS，WSL2 是一个原生 Linux 环境而非类 unix 环境，甚至可以在 App 商店中选择所需要的发行版。而相比于 WSL1，WSL2 采用了 HyperV 虚拟机的方式，解决了 WSL1 不能安装 Docker 等问题。 WSL1 和 WSL2 相比于 WSL1，WSL2 通过虚拟机的方式带来了更完整的 Linux 内核，但这种方式也引入了一些问题，微软给出了下面的图表来展示这些不同： WSL2 不能和 VMWarework Station、VirtualBox 同时运行这一条已经过时了，VirtualBox 和 VMWare Workstation 都发布了支持 WSL2 和 Hyper-V 的新版。 ...

问题描述 在 Python 项目中使用 gRPC 进行通信，跨进程使用时，会出现阻塞或报错的情况（根据 gRPC.io 的版本不同，现象不同）。下面代码展示了一个跨进程使用的 DEMO，主进程向 30001 端口上的 gRPC 服务器发送请求，子进程也向相同的服务器发送请求。 def send(): channel = grpc.insecure_channel('localhost:30001') stub = message_pb2_grpc.GreeterStub(channel) response = stub.SayHello(message_pb2.HelloRequest(name='you')) print(f"Greeter client received 1: " + response.message) def main(): channel = grpc.insecure_channel('localhost:30001') stub = message_pb2_grpc.GreeterStub(channel) response = stub.SayHello2(message_pb2.HelloRequest(name='you')) print("Greeter client received 2: " + response.message) p = multiprocessing.Process(target=send) p.start() p.join() if __name__ == '__main__': main() 使用 gRPC.io 1.28.1 的情况下，会发生报错，主进程可以正常收到服务器的返回，但是子进程报 Socket operation on non-socket。 raise _InactiveRpcError(state) grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with: status = StatusCode.UNAVAILABLE details = "Socket operation on non-socket" debug_error_string = "{"created":"@1587481625.192071231","description":"Error received from peer ipv6:[::1]:50051","file":"src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket operation on non-socket","grpc_status":14}" > 排查过程 根据代码，主进程和子进程分别创建了自己的 Channel，看上去逻辑没什么问题，没有什么思路，所以多尝试几种情况先测试一下吧。首先尝试了一下主进程和子进程请求不同的server，在 30001 和 30002 端口分别启动两个 gRPC Server，然后将客户端代码改为主进程请求 30001 端口，子进程请求 30002 端口，代码可以正常运行。测试到这里就更摸不着头脑了，代码明明写的是主进程子进程分别创建 Channel，现在的现象看上去像是在请求相同服务器的情况下，子进程复用了主进程的socket连接。gRPC 底层使用的是 HTTP2，而 HTTP2 使用了长连接，会不会是这个原因？ ...