MySQL进阶垫脚石：线程长时间处于killed状态怎么破？，dubbo常见面试题

一个月成就技术

于 2024-04-10 21:06:40 发布

阅读量1k

点赞数 14

分类专栏： 2024年程序员学习文章标签： mysql dubbo android

本文链接：https://blog.csdn.net/m0_54816834/article/details/137611082

版权

2024年程序员学习专栏收录该内容

229 篇文章 1 订阅

订阅专栏

2）被kill线程响应kill命令

被kill线程感知（响应）kill命令主要有两种方式：

主动检查： c onne ction1在一些代码处会去主动检查killed状态；
被通过信号量唤醒： connection1在执行某些命令时（如引擎层去做一些操作），会主动去await一个condition，释放掉相应的锁，connection2执行kill命令时，会通过锁和condition唤醒connection1，执行终止操作；

killed状态：

enum killed_state

{

NOT_KILLED=0, KILL_BAD_DATA=1,

KILL_CONNECTION=ER_SERVER_SHUTDOWN, KILL_QUERY=ER_QUERY_INTERRUPTED, KILL_TIMEOUT=ER_QUERY_TIMEOUT,

KILLED_NO_VALUE /* means neither of the states */

};

3）connection真正被kill掉

真正被kill指的是show processlist看不到这个线程的时机。mysql在新建一个connection之后，会不断的去监听连接（do_command），前面提到kill时会主动把连接的socket关闭（shutdown_active_vio)。所以真正连接终止的逻辑是在此处，判断thd_connection_alive的状态是待杀死之后，会关闭connection，并且release_resources，此时再去show processlist，则killed的线程才会消失。相应的pthread也会等待其他连接复用。

killed状态：

if (thd_prepare_connection(thd))

handler_manager->inc_aborted_connects();

else

{

while (thd_connection_alive(thd))

{

if (do_command(thd)) break;

}

end_connection(thd);

}

close_connection(thd, 0, false, false);

thd->get_stmt_da()->reset_diagnostics_area();

thd->release_resources();

// Clean up errors now, before possibly waiting for a new connection.

#if OPENSSL_VERSION_NUMBER < 0x10100000L

ERR_remove_thread_state(0);

#endif /* OPENSSL_VERSION_NUMBER < 0x10100000L */

thd_manager->remove_thd(thd);

Connection_handler_manager::dec_connection_count();

…

channel_info= Per_thread_connection_handler::block_until_new_connection();

//等待新连接复用线程

3、被KILL线程主动检查点和唤醒机制分析

由前面kill过程分析，大致可以分为两种情况，一种是connection1代码一直在执行中(占据cpu)，那么总会执行到某些地方可以检查thd->killed状态，另外一种是connection1线程wait状态，需要其他线程通过信号量唤醒connection1的线程，实现kill中断目的。具体地，这两类又可以分为下面4种情况：

1）第一类：主动检查断点

① connection2发送kill命令时，connection1已执行完命令 (主动检查)

此时connection1阻塞在socket_read上，由于前面提到connection2会去shutdown_active_vio，connection1很容易感知到，执行后续操作，如回滚等。

if (thd_prepare_connection(thd))

handler_manager->inc_aborted_connects();

else

{

while (thd_connection_alive(thd))

{

if (do_command(thd))

break;

}

end_connection(thd);

}

close_connection(thd, 0, false, false);

thd->get_stmt_da()->reset_diagnostics_area();

thd->release_resources(); //clean_up

②内部innodb引擎在获取记录时，也会去判断thd->killed状态，决定是否中断操作，进行返回。

这一类检查点很多。如下面两处：

select每行读取都会检查；

int rr_sequential(READ_RECORD *info)

{

int tmp;

while ((tmp=info->table->file->ha_rnd_next(info->record)))

{

ha_rnd_next can return RECORD_DELETED for MyISAM when one thread is reading and another deleting without locks.

if (info->thd->killed || (tmp != HA_ERR_RECORD_DELETED))

{

tmp= rr_handle_error(info, tmp); break;

}

return tmp;

}

内部innodb引擎在获取记录时，也会去判断thd->killed状态，决定是否中断操作，进行返回。
frame #0: 0x0000000106629a7e mysqld`trx_is_interrupted(trx=0x00007f8266dbd8a0) at ha_innodb.cc:3234:9

frame #1: 0x000000010686d901 mysqld`row_search_mvcc(buf=", mode=PAGE_CUR_G, prebuilt=0x00007f826b81faa0,

match_mode=0, direction=0) at row0sel.cc:5245:6

frame #2: 0x0000000106636cda mysqld`ha_innobase::index_read(this=0x00007f825c8c1430, buf=", key_ptr=0x0000000000000000, key_len=0, find_flag=HA_READ_AFTER_KEY) at ha_innodb.cc:8768:10

frame #3: 0x000000010663798c mysqld`ha_innobase::index_first(this=0x00007f825c8c1430, buf=") at ha_innodb. cc:9186:14

frame #4: 0x0000000106637c2a mysqld`ha_innobase::rnd_next(this=0x00007f825c8c1430, buf=") at ha_innodb.cc: 9284:11

frame #5: 0x000000010563f7a5 mysqld`handler::ha_rnd_next(this=0x00007f825c8c1430, buf=") at handler.cc:2963:

frame #6: 0x0000000105d954d4 mysqld`rr_sequential(info=0x00007f826780d208) at records.cc:517:34

frame #7: 0x0000000105e85c78 mysqld`join_init_read_record(tab=0x00007f826780d1b8) at sql_executor.cc:2504:10

frame #8: 0x0000000105e82a1c mysqld`sub_select(join=0x00007f825e37a4d0, qep_tab=0x00007f826780d1b8,

end_of_records=false) at sql_executor.cc:1284:14

frame #9: 0x0000000105e7f299 mysqld`do_select(join=0x00007f825e37a4d0) at sql_executor.cc:957:12

frame #10: 0x0000000105e7ec26 mysqld`JOIN::exec(this=0x00007f825e37a4d0) at sql_executor.cc:206:10

frame #11: 0x0000000105f5fe90 mysqld`handle_query(thd=0x00007f825e35ec00, lex=0x00007f825e361058,

result=0x00007f825e379cf8, added_options=0, removed_options=0) at sql_select.cc:191:21

frame #12: 0x0000000105f006f7 mysqld`execute_sqlcom_select(thd=0x00007f825e35ec00,

all_tables=0x00007f825e3796b0) at sql_parse.cc:5155:12

frame #13: 0x0000000105ef6527 mysqld`mysql_execute_command(thd=0x00007f825e35ec00, first_level=true) at sql_parse.cc:2826:12

frame #14: 0x0000000105ef3d62 mysqld`mysql_parse(thd=0x00007f825e35ec00, parser_state=0x00007000097d5340) at sql_parse.cc:5584:20

frame #15: 0x0000000105ef0bf0 mysqld`dispatch_command(thd=0x00007f825e35ec00, com_data=0x00007000097d5e78, command=COM_QUERY) at sql_parse.cc:1491:5

frame #16: 0x0000000105ef2e70 mysqld`do_command(thd=0x00007f825e35ec00) at sql_parse.cc:1032:17

frame #17: 0x0000000106081976 mysqld`::handle_connection(arg=0x00007f82681d84f0) at

connection_handler_per_thread.cc:313:13

frame #18: 0x0000000106a4c74c mysqld`::pfs_spawn_thread(arg=0x00007f8268012fc0) at pfs.cc:2197:3

frame #19: 0x00007fff734b6109 libsystem_pthread.dylib`_pthread_start + 148

frame #20: 0x00007fff734b1b8b libsystem_pthread.dylib`thread_start + 15

2）第二类：需要其他线程通过信号量唤醒

① connection2发送kill命令时，connection1处于innodb层wait行锁状态

主要通过awake中的下面这行触发唤醒（也可能由系统的后台线程lock_wait_timeout_thread唤醒）

/* Interrupt target waiting inside a storage engine. */

if (state_to_set != THD::NOT_KILLED)

ha_kill_connection(this);

参考下面 debug 分析的 case3 。

② connection2发送kill命令时，connection1处于msyql层wait状态（由connection2唤醒）

主要通过下面的方法实现唤醒：

/* Broadcast a condition to kick the target if it is waiting on it. */

if (is_killable)

{

mysql_mutex_lock(&LOCK_current_cond);

if (current_cond && current_mutex)

{

DBUG_EXECUTE_IF(“before_dump_thread_acquires_current_mutex”,

{

const char act[]=

“now signal dump_thread_signal wait_for go_dump_thread”;

DBUG_ASSERT(!debug_sync_set_action(current_thd,

STRING_WITH_LEN(act)));

}😉;

mysql_mutex_lock(current_mutex);

mysql_cond_broadcast(current_cond); mysql_mutex_unlock(current_mutex);

}

mysql_mutex_unlock(&LOCK_current_cond);

参考下面debug分析的case4。

三、原因总结

通过上面代码分析可以得知，kill之后会进行回滚操作（大事务）或清理临时表（比如较慢的ddl），都有可能导致长时间处于killed状态。

具体回滚是上面提到的handle_connection中的thd->release_resources()中执行clean_up进行回滚或者在sql_parse中trans_rollback_stmt中。

除开回滚操作的影响，如果本身mysql机器负载较高，一样会导致主动检查thd->killed会有延迟或者影响线程的唤醒调度。

四、案例复现

1、本地debug复现

1）case 1

connection1已执行完命令，connection2去kill连接1

（较为简单，略）

2）case2

connection1正在执行（如parse阶段，还没有真正到innodb层），connection2去kill连接1

（较为简单，略）

3）case3（innodb层唤醒）

新起一个session作为connection0开启事务，update某一行row1

再起一个session作为connection1 update同一行row1

thread #29, stop reason = breakpoint 127.1
frame #0: 0x00000001060f87cb mysqld`os_event::wait(this=0x00007fcce2b16598) at os0event.cc:180:4

frame #1: 0x00000001060f8773 mysqld`os_event::wait_low(this=0x00007fcce2b16598, reset_sig_count=1) at

os0event.cc:366:3

frame #2: 0x00000001060f91ed mysqld`os_event_wait_low(event=0x00007fcce2b16598, reset_sig_count=0) at os0event.cc:611:9

frame #3: 0x00000001060a9332 mysqld`lock_wait_suspend_thread(thr=0x00007fccd90936f0) at lock0wait.cc:315:2

frame #4: 0x00000001061b4f77 mysqld`row_mysql_handle_errors(new_err=0x0000700009f3af6c,

trx=0x00007fcce1cc0ce0, thr=0x00007fccd90936f0, savept=0x0000000000000000) at row0mysql.cc:783:3

frame #5: 0x0000000106212fa6 mysqld`row_search_mvcc(buf=", mode=PAGE_CUR_GE, prebuilt=0x00007fccd9092ea0, match_mode=1, direction=0) at row0sel.cc:6292:6

frame #6: 0x0000000105fd8cda mysqld`ha_innobase::index_read(this=0x00007fccd9091430, buf=“, key_ptr=”\x1e", key_len=514, find_flag=HA_READ_KEY_EXACT) at ha_innodb.cc:8768:10

frame #7: 0x0000000104ff2c67 mysqld`handler::index_read_map(this=0x00007fccd9091430, buf=“, key=”\x1e", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at handler.h:2824:13

frame #8: 0x0000000104fe1f14 mysqld`handler::ha_index_read_map(this=0x00007fccd9091430, buf=“, key=”\x1e", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at handler.cc:3047:3

frame #9: 0x0000000104feeb62 mysqld`handler::read_range_first(this=0x00007fccd9091430, start_key=0x00007fccd9091518, end_key=0x00007fccd9091538, eq_range_arg=true, sorted=true) at handler.cc:7412:13

frame #10: 0x0000000104fec01b mysqld`handler::multi_range_read_next(this=0x00007fccd9091430, range_info=0x0000700009f3bc10) at handler.cc:6477:15

frame #11: 0x0000000104fed4ba mysqld`DsMrr_impl::dsmrr_next(this=0x00007fccd9091698, range_info=0x0000700009f3bc10) at handler.cc:6869:24

frame #12: 0x0000000105fee7f6 mysqld`ha_innobase::multi_range_read_next(this=0x00007fccd9091430, range_info=0x0000700009f3bc10) at ha_innodb.cc:20585:18

frame #13: 0x00000001056ec7c8 mysqld`QUICK_RANGE_SELECT::get_next(this=0x00007fcce2b15fa0) at opt_range.cc: 11247:21

frame #14: 0x00000001057371ad mysqld`rr_quick(info=0x0000700009f3c320) at records.cc:405:29

frame #15: 0x0000000105984e35 mysqld`mysql_update(thd=0x00007fcce585f400, fields=0x00007fcce5863618, values=0x00007fcce58643d8, limit=18446744073709551615, handle_duplicates=DUP_ERROR, found_return=0x0000700009f3cb48, updated_return=0x0000700009f3cb40) at sql_update.cc:819:14

frame #16: 0x000000010598cc87 mysqld`Sql_cmd_update::try_single_table_update(this=0x00007fcce58643c8, thd=0x00007fcce585f400, switch_to_multitable=0x0000700009f3cc07) at sql_update.cc:2927:21

frame #17: 0x000000010598d457 mysqld`Sql_cmd_update::execute(this=0x00007fcce58643c8, thd=0x00007fcce585f400) at sql_update.cc:3058:7

frame #18: 0x000000010589b475 mysqld`mysql_execute_command(thd=0x00007fcce585f400, first_level=true) at sql_parse.cc:3616:26

frame #19: 0x0000000105895d62 mysqld`mysql_parse(thd=0x00007fcce585f400, parser_state=0x0000700009f40340) at sql_parse.cc:5584:20

frame #20: 0x0000000105892bf0 mysqld`dispatch_command(thd=0x00007fcce585f400, com_data=0x0000700009f40e78, command=COM_QUERY) at sql_parse.cc:1491:5

frame #21: 0x0000000105894e70 mysqld`do_command(thd=0x00007fcce585f400) at sql_parse.cc:1032:17

frame #22: 0x0000000105a23976 mysqld`::handle_connection(arg=0x00007fcce2555370) at

connection_handler_per_thread.cc:313:13

frame #23: 0x00000001063ee74c mysqld`::pfs_spawn_thread(arg=0x00007fcce2555f80) at pfs.cc:2197:3

frame #24: 0x00007fff71032109 libsystem_pthread.dylib`_pthread_start + 148

frame #25: 0x00007fff7102db8b libsystem_pthread.dylib`thread_start + 15

可以看到connection1 在等待row1的行锁

开启新的session作为connection2执行kill co nnection1的命令，走到前面代码中分析到的ha_close_connection时，会去中断innodb行锁的等待。堆栈为

thread #30

frame #0: 0x00000001060f910e mysqld`os_event::set(this=0x00007fcce2b16598) at os0event.cc:93:2

frame #1: 0x00000001060f90b5 mysqld`os_event_set(event=0x00007fcce2b16598) at os0event.cc:560:9

frame #2: 0x00000001060aa06e mysqld`lock_wait_release_thread_if_suspended(thr=0x00007fccd90936f0) at lock0wait.cc:411:3

frame #3: 0x0000000106089a99 mysqld`lock_cancel_waiting_and_release(lock=0x00007fccd8866c18) at lock0lock. cc:6789:3

frame #4: 0x0000000106096679 mysqld`lock_trx_handle_wait(trx=0x00007fcce1cc0ce0) at lock0lock.cc:6972:3

frame #5: 0x0000000105ff93a6 mysqld`innobase_kill_connection(hton=0x00007fccd7e094d0,

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）

总目录展示

该笔记共八个节点（由浅入深），分为三大模块。

高性能。秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。该笔记将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这4个方面重点介绍。

一致性。秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。因此，将用一个节点来专门讲解如何设计秒杀减库存方案。

高可用。虽然介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，还要设计一个PlanB来兜底，以便在最坏情况发生时仍然能够从容应对。笔记的最后，将带你思考可以从哪些环节来设计兜底方案。

篇幅有限，无法一个模块一个模块详细的展示（这些要点都收集在了这份《高并发秒杀顶级教程》里），麻烦各位转发一下（可以帮助更多的人看到哟！）

由于内容太多，这里只截取部分的内容。

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

样关键。可想而知，有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。因此，将用一个节点来专门讲解如何设计秒杀减库存方案。

[外链图片转存中…(img-kmTQXcIR-1712754385936)]

[外链图片转存中…(img-BeLntuSo-1712754385936)]

由于内容太多，这里只截取部分的内容。

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-LnnYiVfZ-1712754385936)]

一个月成就技术

关注

14
点赞
踩
6

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录