程数为thread_pool_oversubscribe+1，注意listener线程不包含在内。
thread_pool_high_prio_mode：
高优先级队列的控制参数，有三个值（transactions/statements/none），默认是transactions，三个值的含义如下：
thread_pool_high_prio_tickets：
该参数控制每个连接最多语序多少次被放入高优先级队列中，默认为4294967295，注意这个参数只有在thread_pool_high_prio_mode为transactions的时候才有效果。
thread_pool_idle_timeout：
worker线程最大空闲时间，默认为60秒，超过限制后会退出。
thread_pool_max_threads：
该参数用来限制线程池最大的线程数，超过该限制后将无法再创建更多的线程，默认为100000。
thread_pool_stall_limit：
该参数设置timer线程的检测group是否异常的时间间隔，默认为500ms。
最终配置如下：
#thread pool
thread_handling=pool-of-threads
#Group的数量，默认为系统CPU的个数，充分利用CPU资源
thread_pool_size=24
#每个group的最大线程数为thread_pool_oversubscribe+1
thread_pool_oversubscribe=3
performance_schema=off
#extra connection，防止线程池满的情况下无法登录MySQL
extra_max_connections = 8
extra_port = 33333
备注：线程池在Percona,MariaDB,Oracle MySQL企业版中提供，Oracle MySQL社区版并不提供。
线程池貌似并不会直接导致内存不回收，网上有说同时开启Thread pool和PS会出现内存泄露，但是
目前Percona server 5.7.21-20+版本已经修复了这个问题，显然是不存在的。
慢查询
由于是生产环境，这个问题拖得时间有点长，那么慢查询会不会影响内存使用问题呢？带着这个问题，查看了慢查询后台列表，在数据库奔溃的前一个时间段，的确有不少慢查询语句。但是这并不能在一定程度上说明问题，由于服务器的 MySql 服务在杀死之前，内存已经见底，此时连接数并不多，也就三四十来个左右，大多处于休眠状态，并且此时已经占用了大部分的Swap空间。也就是说，在资源有限的情况下必定会出现不少慢查询语句。
小结
其实这个"意外"一点也不意外，其实已经发生了多次了。但是还是做个小结吧，因为最终没有确认问题出现在哪里，所以还是发布了吧，万一有专业的DBA遇到类似的问题还可以小小的解惑一下。
参考
https://bugs.mysql.com/bug.php?id=91861
https://bugs.mysql.com/bug.php?id=91710
https://dev.mysql.com/doc/refman/5.7/en/memory-use.html
https://www.percona.com/blog/2018/06/28/what-to-do-when-mysql-runs-out-of-memory-troubleshooting-guide/
https://dev.mysql.com/doc/refman/5.7/en/thread-pool-tuning.html