浅析goland等待锁问题

2024-12-08 16:58:35

问题描述：

向后台发送了一个URL请求，竟然一直卡住，没有返回，就一直卡着

问题分析定位：

一开始还以为是网络，还是什么其它奇怪的原因，毕竟之前好好的。

这里应该第一时间思考环境的变化，网络、程序版本、还是什么地方变化了。

后来又试了好几次，发现还是一样，想到了将Pod的数目改成了2个，于是估计是等待锁或者死锁之类的。

通过以下链接获取调试信息：
curl “127.0.0.1:43411/debug/pprof/goroutine?debug=1” > 1.out
curl “127.0.0.1:43411/debug/pprof/goroutine?debug=2” > 1.log

搜索卡住的请求方法名，果真搜到一些，goroutine 17002 [semacquire, 5 minutes]:表示17002这个goroutine正在等待获取锁，等了5分钟了。

又有一个正在运行中的同名方法，估计是大家都在等它的锁，看来代码，果然有一个锁。
但是这个goroutine调用栈最上层是SetDataNodeCarry，看到其方法内部，发现其也加了一个锁，不过其就是简单的对一个字段的变更进行加锁。
分析其使用的锁相关的代码，大家没有重叠，每一次加锁只不过是保证数据的原子性和一致性而已，所以不会有死锁的问题。

阅读SetDataNodeCarry附近的代码，有一个for availCarryCount < needSelectedNum {}，之前没仔细看，这里竟然可能是一个死循环，分析了一下环境的变化，果然是因为环境不同了，导致这里的循环无法跳出。

总结

遇到此类问题首先不能慌，之后不能逃避问题。

需要将问题尽可能地记录，以便于还原，同时还要基于现在的情况进行调试，千万不能想着重启会好，不能逃避问题。

后面解决问题的步骤还可以，不过这个问题本身也不是很难。

------------记录

1 @ 0x47fc42 0x80fb0d 0x811270 0x80b86e 0x7ba758 0x7e0686 0x7f24fa 0x81d712 0x6ff9b4 0x7018b6 0x702c88 0x6fe971 0x469581
#0x47fc41 sync.(*RWMutex).Unlock+0xb1     /usr/local/go/src/sync/rwmutex.go:113
#0x80fb0c [go文件路径]m.(*Pod).SetDataNodeCarry+0x6c  /go/src/[go文件路径]m/t.go:777
#0x81126f [go文件路径]m.pts.ptsn+0x5f /go/src/[go文件路径]m/t.go:1059
#0x80b86d [go文件路径]m.(*t).ctcpd+0x83d /go/src/[go文件路径]m/t.go:453
#0x7ba757 [go文件路径]m.(*c).cDP+0x1e7  /go/src/[go文件路径]m/c.go:558
#0x7e0685 [go文件路径]m.(*m).cDP+0x375  /go/src/[go文件路径]m/handle_admin.go:353
#0x7f24f9 [go文件路径]m.(*m).ServeHTTP+0x1659   /go/src/[go文件路径]m/http_server.go:188
#0x81d711 [go文件路径]m.(*m).handlerWithInterceptor.func1+0x81  /go/src/[go文件路径]m/http_server.go:160
#0x6ff9b3 net/http.HandlerFunc.ServeHTTP+0x43    /usr/local/go/src/net/http/server.go:1995
#0x7018b5 net/http.(*ServeMux).ServeHTTP+0x1d5    /usr/local/go/src/net/http/server.go:2375
#0x702c87 net/http.serverHandler.ServeHTTP+0xa7    /usr/local/go/src/net/http/server.go:2774
#0x6fe970 net/http.(*conn).serve+0x850     /usr/local/go/src/net/http/server.go:1878

2 @ 0x43c20f 0x44c609 0x44c5df 0x44c37d 0x47ecb9 0x7ba6ad 0x7e0686 0x7f24fa 0x81d712 0x6ff9b4 0x7018b6 0x702c88 0x6fe971 0x469581
#0x44c37c sync.runtime_SemacquireMutex+0x3c   /usr/local/go/src/runtime/sema.go:71
#0x47ecb8 sync.(*Mutex).Lock+0x108    /usr/local/go/src/sync/mutex.go:134
#0x7ba6ac [go文件路径]m.(*c).cDP+0x13c /go/src/[go文件路径]m/c.go:554
#0x7e0685 [go文件路径]m.(*m).cDP+0x375 /go/src/[go文件路径]m/handle_admin.go:353
#0x7f24f9 [go文件路径]m.(*m).ServeHTTP+0x1659  /go/src/[go文件路径]m/http_server.go:188
#0x81d711 [go文件路径]m.(*m).handlerWithInterceptor.func1+0x81 /go/src/[go文件路径]m/http_server.go:160
#0x6ff9b3 net/http.HandlerFunc.ServeHTTP+0x43   /usr/local/go/src/net/http/server.go:1995
#0x7018b5 net/http.(*ServeMux).ServeHTTP+0x1d5   /usr/local/go/src/net/http/server.go:2375
#0x702c87 net/http.serverHandler.ServeHTTP+0xa7   /usr/local/go/src/net/http/server.go:2774
#0x6fe970 net/http.(*conn).serve+0x850    /usr/local/go/src/net/http/server.go:1878

goroutine 13994 [runnable]:
sync.(*Mutex).Lock(0xc002300468)
	/usr/local/go/src/sync/mutex.go:72 +0x2c9
sync.(*RWMutex).Lock(0xc002300468)
	/usr/local/go/src/sync/rwmutex.go:93 +0x2d
[go文件路径]m.(*Pod).SetDataNodeCarry(0xc0023003f0, 0x4024000000000000)
	/go/src/[go文件路径]m/t.go:774 +0x36
[go文件路径]m.pts.ptsn(0xc003b17810, 0x2, 0x2, 0x0, 0x3)
	/go/src/[go文件路径]m/t.go:1059 +0x60
[go文件路径]m.(*t).ctcpd(0xc0000ef090, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x3, 0x6, 0xc002275958, ...)
	/go/src/[go文件路径]m/t.go:453 +0x83e
[go文件路径]m.(*c).cDP(0xc00223c000, 0xc00286e673, 0xe, 0xc00286e65f, 0x6, 0x0, 0x0, 0x0)
	/go/src/[go文件路径]m/c.go:558 +0x1e8
[go文件路径]m.(*m).cDP(0xc0009aca90, 0xabfd80, 0xc0031a1260, 0xc00296be00)
	/go/src/[go文件路径]m/handle_admin.go:353 +0x376
[go文件路径]m.(*m).ServeHTTP(0xc0009aca90, 0xabfd80, 0xc0031a1260, 0xc00296be00)
	/go/src/[go文件路径]m/http_server.go:188 +0x165a
[go文件路径]m.(*m).handlerWithInterceptor.func1(0xabfd80, 0xc0031a1260, 0xc00296be00)
	/go/src/[go文件路径]m/http_server.go:160 +0x82
net/http.HandlerFunc.ServeHTTP(0xc000990300, 0xabfd80, 0xc0031a1260, 0xc00296be00)
	/usr/local/go/src/net/http/server.go:1995 +0x44
net/http.(*ServeMux).ServeHTTP(0x10a3520, 0xabfd80, 0xc0031a1260, 0xc00296be00)
	/usr/local/go/src/net/http/server.go:2375 +0x1d6
net/http.serverHandler.ServeHTTP(0xc0000dad00, 0xabfd80, 0xc0031a1260, 0xc00296be00)
	/usr/local/go/src/net/http/server.go:2774 +0xa8
net/http.(*conn).serve(0xc003b19860, 0xac1d80, 0xc0009a9e40)
	/usr/local/go/src/net/http/server.go:1878 +0x851
created by net/http.(*Server).Serve
	/usr/local/go/src/net/http/server.go:2884 +0x2f4

goroutine 17002 [semacquire, 5 minutes]:
sync.runtime_SemacquireMutex(0xc0026fc460, 0x419400)
	/usr/local/go/src/runtime/sema.go:71 +0x3d
sync.(*Mutex).Lock(0xc0026fc45c)
	/usr/local/go/src/sync/mutex.go:134 +0x109
[go文件路径]m.(*c).cDP(0xc00223c000, 0xc00002a083, 0xe, 0xc00002a06f, 0x6, 0x0, 0x0, 0x0)
	/go/src/[go文件路径]m/c.go:554 +0x13d
[go文件路径]m.(*m).cDP(0xc0009aca90, 0xabfd80, 0xc0031a0620, 0xc002988900)
	/go/src/[go文件路径]m/handle_admin.go:353 +0x376
[go文件路径]m.(*m).ServeHTTP(0xc0009aca90, 0xabfd80, 0xc0031a0620, 0xc002988900)
	/go/src/[go文件路径]m/http_server.go:188 +0x165a
[go文件路径]m.(*m).handlerWithInterceptor.func1(0xabfd80, 0xc0031a0620, 0xc002988900)
	/go/src/[go文件路径]m/http_server.go:160 +0x82
net/http.HandlerFunc.ServeHTTP(0xc000990300, 0xabfd80, 0xc0031a0620, 0xc002988900)
	/usr/local/go/src/net/http/server.go:1995 +0x44
net/http.(*ServeMux).ServeHTTP(0x10a3520, 0xabfd80, 0xc0031a0620, 0xc002988900)
	/usr/local/go/src/net/http/server.go:2375 +0x1d6
net/http.serverHandler.ServeHTTP(0xc0000dad00, 0xabfd80, 0xc0031a0620, 0xc002988900)
	/usr/local/go/src/net/http/server.go:2774 +0xa8
net/http.(*conn).serve(0xc003b18640, 0xac1d80, 0xc00298e940)
	/usr/local/go/src/net/http/server.go:1878 +0x851
created by net/http.(*Server).Serve
	/usr/local/go/src/net/http/server.go:2884 +0x2f4

goroutine 14532 [semacquire, 11 minutes]:
sync.runtime_SemacquireMutex(0xc0026fc460, 0x419400)
	/usr/local/go/src/runtime/sema.go:71 +0x3d
sync.(*Mutex).Lock(0xc0026fc45c)
	/usr/local/go/src/sync/mutex.go:134 +0x109
[go文件路径]m.(*c).cDP(0xc00223c000, 0xc003f74303, 0xe, 0xc003f742ef, 0x6, 0x0, 0x0, 0x0)
	/go/src/[go文件路径]m/c.go:554 +0x13d
[go文件路径]m.(*m).cDP(0xc0009aca90, 0xabfd80, 0xc00454a620, 0xc004544800)
	/go/src/[go文件路径]m/handle_admin.go:353 +0x376
[go文件路径]m.(*m).ServeHTTP(0xc0009aca90, 0xabfd80, 0xc00454a620, 0xc004544800)
	/go/src/[go文件路径]m/http_server.go:188 +0x165a
[go文件路径]m.(*m).handlerWithInterceptor.func1(0xabfd80, 0xc00454a620, 0xc004544800)
	/go/src/[go文件路径]m/http_server.go:160 +0x82
net/http.HandlerFunc.ServeHTTP(0xc000990300, 0xabfd80, 0xc00454a620, 0xc004544800)
	/usr/local/go/src/net/http/server.go:1995 +0x44
net/http.(*ServeMux).ServeHTTP(0x10a3520, 0xabfd80, 0xc00454a620, 0xc004544800)
	/usr/local/go/src/net/http/server.go:2375 +0x1d6
net/http.serverHandler.ServeHTTP(0xc0000dad00, 0xabfd80, 0xc00454a620, 0xc004544800)
	/usr/local/go/src/net/http/server.go:2774 +0xa8
net/http.(*conn).serve(0xc002e17540, 0xac1d80, 0xc002a74780)
	/usr/local/go/src/net/http/server.go:1878 +0x851
created by net/http.(*Server).Serve
	/usr/local/go/src/net/http/server.go:2884 +0x2f4

总结

到此这篇关于goland等待锁问题的文章就介绍到这了,更多相关goland等待锁内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

浅析goland等待锁问题

问题描述: 向后台发送了一个URL请求,竟然一直卡住,没有返回,就一直卡着问题分析定位: 一开始还以为是网络,还是什么其它奇怪的原因,毕竟之前好好的. 这里应该第一时间思考环境的变化,网络.程序版本.还是什么地方变化了. 后来又试了好几次,发现还是一样,想到了将Pod的数目改成了2个,于是估计是等待锁或者死锁之类的. 通过以下链接获取调试信息: curl "127.0.0.1:43411/debug/pprof/goroutine?debug=1" > 1.out curl &
浅析JAVA Lock锁原理

同样是锁,先说说synchronized和lock的区别: synchronized是java关键字,是用c++实现的:而lock是用java类,用java可以实现 synchronized可以锁住代码块,对象和类,但是线程从开始获取锁之后开发者不能进行控制和了解:lock则用起来非常灵活,提供了许多api可以让开发者去控制加锁和释放锁等等. 写个Demo static Lock lock = new ReentrantLock();public static void main(String[
Mysql查询正在执行的事务以及等待锁的操作方式

使用navicat测试学习: 首先使用set autocommit = 0;(取消自动提交,则当执行语句commit或者rollback执行提交事务或者回滚) 在打开一个执行update 查询正在执行的事务: SELECT * FROM information_schema.INNODB_TRX 根据这个事务的线程ID(trx_mysql_thread_id): 从上图看出对应的mysql 线程:一个94362 (第二个正在等待锁)另一个是93847(第一个update 正在执行没有提交事务
redis中RedissonLock如何实现等待锁的

目录前言问题方案 tryLock unlockInnerAsync 思考前言经常会有到这样的需求,就是在一个查询接口,第一次查询的时候,如果没有查询到就要执行初始化方法,初始化数据出来,之后的查询就可以直接查询库里的数据了.这样设计的目的是,如果需要初始化的数据特别大,无法再一次调用方法里处理完,或者说数据并不是每条都需要初始化,这种情况下,优先查询的数据优先初始化. 问题这种方案随之而来就会引发一个问题.查询接口众所周知是个自然幂等的,不需要我们额外去做幂等处理.但是在方案中,这个
浅析Sql server锁,独占锁,共享锁,更新锁,乐观锁,悲观锁

锁有两种分类方法.(1) 从数据库系统的角度来看锁分为以下三种类型: •独占锁(Exclusive Lock)独占锁锁定的资源只允许进行锁定操作的程序使用,其它任何对它的操作均不会被接受.执行数据更新命令,即INSERT. UPDATE 或DELETE 命令时,SQL Server 会自动使用独占锁.但当对象上有其它锁存在时,无法对其加独占锁.独占锁一直到事务结束才能被释放. •共享锁(Shared Lock)共享锁锁定的资源可以被其它用户读取,但其它用户不能修改它.在SELECT 命令执行时,
浅析Redis分布式锁

近期工作遇到需要业务场景如下,需要每天定时推送给另一系统一批数据,但是由于系统是集群部署的,会造成统一情况下任务争用的情况,所以需要增加分布式锁来保证一定时间范围内有一个Job来完成定时任务. 前期考虑的方案有采用ZooKeeper分布式任务,Quartz分布式任务调度,但是由于Zookeeper需要增加额外组件,Quartz需要增加表,并且项目中现在已经有Redis这一组件存在,所以考虑采用Redis分布式锁的情况来完成分布式任务抢占这一功能记录一下走过的弯路. 第一版本: @Overrid
Java synchronized重量级锁实现过程浅析

目录一.什么是重量级锁二.重量级锁的演示三.重量级锁的原理四.锁的优缺点对比一.什么是重量级锁当有大量的线程都在竞争同一把锁的时候,这个时候加的锁,就是重量级锁. 这个重量级锁其实指的就是JVM内部的ObjectMonitor监视器对象: ObjectMonitor() { _header = NULL; //锁对象的原始对象头 _count = 0; //抢占当前锁的线程数量 _waiters = 0, //调用wait方法后等待的线程数量 _recursions = 0; //记
快速查出Oracle数据库中锁等待的方法

通常在大型数据库系统中,为了保证数据的一致性,在对数据库中的数据进行操作时,系统会进行对数据相应的锁定. 这些锁定中有"只读锁"."排它锁","共享排它锁"等多种类型,而且每种类型又有"行级锁"(一次锁住一条记录),"页级锁"(一次锁住一页,即数据库中存储记录的最小可分配单元),"表级锁"(锁住整个表).若为"行级排它锁",则除被锁住的该行外,该表中其它行均可被其它的
MySQL锁等待与死锁问题分析

前言: 在 MySQL 运维过程中,锁等待和死锁问题是令各位 DBA 及开发同学非常头痛的事.出现此类问题会造成业务回滚.卡顿等故障,特别是业务繁忙的系统,出现死锁问题后影响会更严重.本篇文章我们一起来学习下什么是锁等待及死锁,出现此类问题又应该如何分析处理呢? 1.了解锁等待与死锁出现锁等待或死锁的原因是访问数据库需要加锁,那你可能要问了,为啥要加锁呢?原因是为了确保并发更新场景下的数据正确性,保证数据库事务的隔离性. 试想一个场景,如果你要去图书馆借一本<高性能MySQL>,为了防止有人
浅谈Java并发编程之Lock锁和条件变量

简单使用Lock锁 Java 5中引入了新的锁机制--java.util.concurrent.locks中的显式的互斥锁:Lock接口,它提供了比synchronized更加广泛的锁定操作.Lock接口有3个实现它的类:ReentrantLock.ReetrantReadWriteLock.ReadLock和ReetrantReadWriteLock.WriteLock,即重入锁.读锁和写锁.lock必须被显式地创建.锁定和释放,为了可以使用更多的功能,一般用ReentrantLock为其实例

浅析goland等待锁问题

相关推荐

随机推荐