hello,大家好呀,我是小楼。

最近我又双叒叕写了个BUG,一个线上服务死锁了,不过幸亏是个新服务,没有什么大影响。

出问题的是Go的读写锁,如果你是写Java的,不必划走,更要看看本文,本文的重点在于Java和Go的读写锁对比,甚至看完后你会有一个隐隐的感觉:Go的读写锁是不是有BUG?

故障回放

背景简单抽象一下:一个server服务(Go语言实现),提供了一个http接口,另有一个client服务来调用这个接口,整体架构非常简单,甚至都不用画架构图你也能够理解。

这两个服务上线运行了一段时间都没什么问题,突然有一天client调用这个server的接口全都超时了。

碰到这种问题,第一时间去查看日志和监控,client端全是超时日志,server端日志没有异常,甚至连请求的监控都没有上报,仿佛client端的请求没有到达server端一样。

于是去server服务器上手动请求了一下接口,结果卡主不动,这下排除了client,一定是server端出了问题。

这种卡死的问题其实很好查,直接用pprof看协程卡在哪里基本就能得出结论(和Java的jstack类似的工具),但这个服务没有开启pprof,只能改了代码打开pprof重新发布,等待下次问题复现。

好在运气不错,2天后问题就出来了,用pprof看下程序卡在了哪里:

原来卡在了一个判断集群或服务是否是小流量的地方,该接口会接受一个集群名或服务名的参数,然后判断该集群或服务是否是小流量集群,进而做一系列事,至于做了啥不重要。小流量集群是配置在配置中心中。

我把这段代码摘出来(图中是走的判断集群分支,下面代码以更简单的服务分支讲解,底层一致)。为了避免空洞,这里我先简单讲解一下程序的逻辑:

  • 首先小流量的配置定义了一个读写锁(sync.RWMutex),以及在内存中保持了哪些服务需要灰度的规则(scopesMap)

  • 配置变更时调用reset刷新这个scopesMap,用写锁,后续逻辑省略

  • 判断是否为灰度服务,先加读锁看看规则是否存在:

  • 再加锁判断服务是否命中规则:

这样圈出重点,你可能一眼就看出问题了,读锁加了两次,第二次没有必要,属于手误了。确实,删除第二个加读锁的代码就没问题了。如果事情到这就结束了,那这篇文章也没有必要写了,下面我们分析下为什么会死锁。

为什么会死锁

看到这个结果,我第一反应是Go的锁的重入性问题。

熟悉Java的同学对锁的重入并不陌生,以防有读者不明白锁的重入性,我用一句话来概括:

可重入锁就是可以重复进入的锁,也叫递归锁

Java中有一个ReentrantLock,比如这样,重复加锁是没有问题的:

但Go里面的锁是不可重入的:

这个坑我也踩过,这是Go的实现问题。只要你愿意,用Java也能实现不可重入锁,但Java中大多数使用的还是可重入锁,因为用起来比较方便。

至于Go为什么不实现一个可重入的锁,可以参考煎鱼大佬的这篇文章《Go 为什么不支持可重入锁?》 ,其原因总结起来就是Go的设计者觉得重入锁是个不好的设计,所以没有采纳。不过我觉得这篇文章的评论更精彩:

说到这,你可能会说,上面出问题的明明是读写锁(sync.RWMutex),读写锁的特点是什么?

  • 读与读之间不互斥
  • 读与写、写与写之间互斥

既然读锁之间是不互斥,也就是可加两次读锁,那么读锁必然是可重入的。我们写个demo测试下:

果然如我们所想,顺便看一下加读锁的逻辑:

看我框出的代码,如果有写锁在等待,读锁需要等写锁!

这是什么逻辑?

如果一个协程已经拿到了读锁,另一个协程尝试加写锁,这时应该加不了,没什么问题。如果这个读锁的协程再去拿读锁,需要等写锁,这就死锁了啊!

为了验证,我构造了一个demo:

这段代码按①、②、③顺序执行,第②段写锁需要等第①个读锁释放,第③段读锁需要等第②段写锁释放,最终就是一个死锁的逻辑。

仔细想,这里面最有争议的要属已经拿到读锁再次进入读锁需要等写锁这个逻辑。

Java中是这样的吗?写个demo试试:

Java一点事都没有,这是为啥?遇事不决,看源码!但Java的源码太长,又不是本文重点,所以就只说几点重要的结论:

  1. Java的ReentrantReadWriteLock支持锁降级,但不能升级,即获取了写锁的线程,可以继续获取读锁,但获取读锁的线程无法再获取写锁;
  2. ReentrantReadWriteLock实现了公平和非公平两种锁,公平锁的情况下,获取读锁、写锁前需要看同步队列中是否先线程在我之前排队;非公平锁的情况下:写锁可以直接抢占锁,但是读锁获取有一个让步条件,如果当前同步队列head.next是一个写锁在等待,并且自己不是重入的,就要让步等待。

在Java的实现下,如果一个线程持有了读锁,写锁自然是需要等待的,但是持有读锁的线程也可以再次重入该读锁。

我们发现Java和Go的读写锁实现不一致,这个不一致也就是导致我们写出BUG的原因。

这合理吗

抛开实现,我们思考一下这样合理吗?

  • 一个协程(或线程)已经获取到了读锁,别的协程(线程)获取写锁时必然需要等待读锁的释放
  • 既然这个协程(或线程)已经拥有了这个读锁,那么为什么再次获取读锁时需要管别的写锁是否等待呢?

可以想象病人排队看医生,前面一个病人向医生问诊,进去后把门关上,在里面无论问多长时间(理论上)是他的权利,后面的病人在他没出来前是不能打开门的。

但Go的实现却是,前一个病人每问完一句话得看一眼门外是否有人在等,如果有人在等,那他就要等门外的人问完才能问,但门外的人又在等他问,所以大家死锁了,谁都别想看完病。

是不是细思下来,感觉这是不是Go的一个BUG?

Go为什么这么实现

我尝试去github上搜索了一下,发现了这个issue:

https://github.com/golang/go/issues/30657

从标题就能看出他遇到了和我一样的问题:

Read-locking shouldn't hang if thread has already a write-lock? #30657

看看里面有人是怎么回答的:

这位大佬说,这不符合Go锁的原理,Go的锁是不知道协程或者线程信息的,只知道代码调用先后顺序,即读写锁无法升级或降级。

Java中的锁记录了持有者(线程id),但Go的锁是不知道持有者是谁,所以获取了读锁之后再次获取读锁,这里的逻辑是区分不了是持有者还是其他的协程,所以就统一处理。

这点其实在Go源码的注释中体现了,我也是后来才注意到:

翻译一下是:

如果一个协程持有读锁,另一个协程可能会调用Lock加写锁,那么再也没有一个协程可以获得读锁,直到前一个读锁释放,这是为了禁止读锁递归。也确保了锁最终可用,一个阻塞的写锁调用会将新的读锁排除在外。

不过这个警示实在是太不起眼了,大概就是这个效果:

这一幕像极了产品和程序员:

  • 产品经理:我要实现这个功能,怎么实现我不管
  • Go:这破坏了我的设计原则,不接受这个功能
  • 产品经理:大家都退一步,你换个代价小的方法解决吧

于是,程序员在读写锁上写下了一段注释:

最后

这个死锁的坑确实很容易踩,尤其是Java程序员来写Go,所以我们写Go代码时还是得写得更Go一点才行。

Go的设计者比较「偏执」,认为「不好」的设计坚决不去实现,就如锁的实现不应该依赖线程、协程信息;可重入(递归)锁是一种不好的设计。所以这种看似有BUG的设计,也存在一定的道理

当然每个人都有自己的想法,你觉得Go的读写锁这样实现合理吗?

如果你看完觉得有点收获,给个在看吧,你的支持是我持续创作的动力~


搜索关注微信公众号"捉虫大师",后端技术分享,架构设计、性能优化、源码阅读、问题排查、踩坑实践。

这不会又是一个Go的BUG吧?的更多相关文章

  1. 一个iOS6系统bug+一个iOS7系统bug

    先看实际工作中遇到的两个bug:(1)iPhone Qzone有一个导航栏背景随着页面滑动而渐变的体验,当页面滑动到一定距离时,会改变导航栏上title文本的颜色,但是有一个莫名其妙的bug,如下:

  2. FIREDAC(DELPHI10 or 10.1)提交数据给ORACLE数据库的一个不是BUG的BUG

    发现FIREDAC(DELPHI10 or 10.1)提交数据给ORACLE数据库的一个不是BUG的BUG,提交的表名大小写是敏感的. 只要有一个表名字母的大小写不匹配,ORACLE就会认为是一个不认 ...

  3. pycharm下: conda installation is not found ----一个公开的bug的解决方案

    pycharm  conda installation is not  found ----一个公开的bug的解决方案 pycharm+anaconda 是当前的主流的搭建方案,但是常出现上述问题. ...

  4. 返回一个集合对象,同时这个集合的对象的属性又是一个集合对象的处理方法(ViewModel)

    如果遇到需要返回一个集合对象,其中该集合中的属性又是一个集合.第一种:可在考虑用外键关联,比如在控制器中可以采用预先加载的方式加载关联的数据,比如 RoleManager.Roles.Include& ...

  5. 一个神奇的bug:OOM?优雅终止线程?系统内存占用较高?

    摘要:该项目是DAYU平台的数据开发(DLF),数据开发中一个重要的功能就是ETL(数据清洗).ETL由源端到目的端,中间的业务逻辑一般由用户自己编写的SQL模板实现,velocity是其中涉及的一种 ...

  6. python基础练习题(一个整数,它加上100后是一个完全平方数,再加上168又是一个完全平方数,请问该数是多少?)

    day2 --------------------------------------------------------------- 实例003:完全平方数 题目: 一个整数,它加上100后是一个 ...

  7. salesforce零基础学习(一百一十五)记一个有趣的bug

    本篇参考:https://help.salesforce.com/s/articleView?language=en_US&type=1&id=000319486 page layou ...

  8. 调试一个socket通信bug的心理过程和反思

    背景交代.最近在玩lua的服务端编码, 有项目A,B,AB都是同一个模子的.我手上有A的winsocket客户端和服务端的代码,B项目早期的一份linux下的lua client.服务端.客户端都是L ...

  9. 从Linux 2.6.8内核的一个TSO/NAT bug引出的网络问题排查观点(附一个skb的优化点)

    梦中没有错与对,梦中没有恨和悔...最好闭上你的嘴.这样才算可爱...我不会说:这不公道,我不能接受.我会用朴素的文字记录点点滴滴,早上4点多起来,一气呵成最近的收获与评价,愤慨与忏悔. 四年多前的一 ...

随机推荐

  1. GopherCon SG 2019 "Understanding Allocations" 学习笔记

    本篇是根据 GopherCon SG 2019 "Understanding Allocations" 演讲的学习笔记. Understanding Allocations: th ...

  2. 6.2 计划任务crond

    创建.编辑计划任务的命令为crontab -e,查看当前计划任务的命令为crontab -l,删除某条计划任务的命令为crontab -r. 参数 作用 -e 编辑计划任务 -u 指定用户名称 -l ...

  3. Oracle 存储过程使用总结

    参考 https://blog.csdn.net/weixin_41968788/article/details/83659164/ 创建 注意:一定不要漏掉了语句末尾的分号 DBMS_OUTPUT. ...

  4. 老生常谈系列之Aop--JDK动态代理的底层实现原理

    老生常谈系列之Aop--JDK动态代理的底层实现原理 前言 在Aop系列里面有两篇文章,分别是老生常谈系列之Aop--Spring Aop原理浅析和老生常谈系列之Aop--Spring Aop源码解析 ...

  5. 尾递归与 memorize 优化

    尾递归与 memorize 优化 本文写于 2020 年 12 月 10 日 递归 递归是一种非常常见的算法思维,在大家刚开始学编程的时候应该就会接触到. 我们可以这么理解递归: function 讲 ...

  6. Redis 的数据过期了就会马上删除么?

    码哥,当 key 达到过期时间,Redis 就会马上删除么? 先说结论,并不会立马删除,Redis 有两种删除过期数据的策略: 定期选取部分数据删除: 惰性删除: 该命令在 Redis 2.4 版本, ...

  7. [java并发编程]基于信号量semaphore实现限流器

    目录 一.什么是信号量 二.信号量类Semaphore 三.实现限流器 欢迎关注我的博客,更多精品知识合集 一.什么是信号量 "信号量"在编程术语中使用单词semaphore,那什 ...

  8. 169. Majority Element - LeetCode

    Question 169. Majority Element Solution 思路:构造一个map存储每个数字出现的次数,然后遍历map返回出现次数大于数组一半的数字. 还有一种思路是:对这个数组排 ...

  9. yolov2学习笔记

    Yolov2学习笔记 yolov2在yolov1的基础上进行一系列改进: 1.比如Batch Normalization,High Resolution Classifier,使用Anchor Box ...

  10. vs 快速定位文件

    在进行web开发时,我们经常需要在文件之间进行切换,每次在VS的解决方案中找文件然后打开 非常浪费时间,有没有比较快捷点的方法呢? 1.使用  ReSharper 插件 ReSharper 插件可以在 ...