Pyhon 线程里获取操作系统层面的进程 ID 和 线程 ID,太棒了

python的多线程坑坑不断… …

python的threading因为封装的太好, 很多本源的东西在threading对象里是拿不到的. 首先需要说明的是 python threading的name跟ident，这些看起来是线程名字，线程id其实只是个标识，注意是标识而已. 简单过了下threading创建对象及启动线程的代码，发现ident跟pstree查到的线程id是两码事.

该文章写的有些乱，欢迎来喷 ! 另外文章后续不断更新中，请到原文地址查看更新http://xiaorui.cc/?p=3017

我在 stackoverflow 查询到了一些关于pyhton线程id的获取方式，但大多数人其实对线程id是不关心的，他们会利用threading给予的threading.currentThread().ident threading.currentThread().name来识别线程. 最后在查到一老外写的使用ctypes调用系统的动态链接库libc.so.6 来获取线程id的方法, 当然事实证明是有效果的.

老外的连接 http://blog.devork.be/2010/09/finding-linux-thread-id-from-within.html

ctypes是Python的一个外部库，提供和C语言兼容的数据类型，可以很方便地调用C DLL中的函数. 我对这个ctypes理解也不深入，在以前的项目中用过，表示有些粗暴.

废话不多说, 直接上python ctypes样例，关于这186,224,178不知道啥意思.

import ctypes
for id in [39,186, 224, 178]:
    tid = ctypes.CDLL('libc.so.6').syscall(id)  #syscall系统调用

下面是python threading获取线程id的实例代码:

#xiaorui.cc

#coding:utf-8
import os
import threading
import ctypes
import time
import requests

def pthread_level1(i):
    print "workor id :%s"%i
    #获取threading对象的标识ident
    print threading.currentThread()
    print threading.currentThread().ident
    print "threaing id: ",ctypes.CDLL('libc.so.6').syscall(186)
    d = requests.get("http://www.google.com")
    time.sleep(100)
    return


if __name__ == "__main__":
    l = []
    for i in xrange(5):
        t = threading.Thread(target=pthread_level1,args=(i,))
        l.append(t)
    for i in l:
        i.start()
    #查看进程跟线程的关系
    os.system("pstree -p " + str(os.getpid()))
    for i in l:
        i.join()

    print "Sub-process done."

这是上面py代码运行后的结果, 跟我们预期的效果一致.

[ruifengyun@wx-test-social11:~]$python a.py
workor id :0
<Thread(Thread-1, started 140665607177984)>
 workor id :1
140665607177984<Thread(Thread-2, started 140665596688128)>

140665596688128workor id :2

threaing id:  24828
<Thread(Thread-3, started 140665586198272)>
140665586198272
threaing id:  24829
threaing id:  workor id :3
<Thread(Thread-4, started 140665575708416)>
140665575708416
threaing id:  24830
24827
workor id :4
<Thread(Thread-5, started 140665565218560)>
140665565218560
threaing id:  24831
python(24826)─┬─pstree(24832)
              ├─{python}(24827)
              ├─{python}(24828)
              ├─{python}(24829)
              ├─{python}(24830)
              └─{python}(24831)

可以另起一个终端使用pstree -p pid看看是否正确.

[ruifengyun@wx-test-social11:~]$pstree -p 24826
python(24826)─┬─{python}(24827)
              ├─{python}(24828)
              ├─{python}(24829)
              ├─{python}(24830)
              └─{python}(24831)

发散下 Python 怎么获取进程的名字：

root@robert-Ubuntu:~# python
Python 2.7.12 (default, Jul 21 2020, 15:19:50) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import  psutil
>>> for proc in psutil.process_iter():
...         print("pid-%d,name:%s" % (proc.pid,proc.name()))
... 
pid-1,name:systemd
pid-2,name:kthreadd
pid-3,name:kworker/0:0
......
pid-2106,name:bash
pid-2166,name:python

那么我们费尽心思取到python的线程id是为了什么?
strace -p pid/线程 的状态. 可以看到24831线程正在建立google.com的连接, 很明显这连接被拒了.

[ruifengyun@wx-test-social11:~]$strace -p 24826
Process 24826 attached - interrupt to quit
futex(0x1abfcd0, FUTEX_WAIT_PRIVATE, 0, NULL
^C <unfinished ...>
Process 24826 detached

[ruifengyun@wx-test-social11:~]$strace -p 24828
Process 24828 attached - interrupt to quit
connect(8, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr
("216.58.221.228")}, 16 

其中提到的老外的文章：

So I’ve got a multi-threaded application and suddenly I notice there’s one thread running away and using all CPU. Not good, probably a loop gone wrong. But where? One way to find this is revert history in the VCS and keep trying it out till you find the bad commit. Another way is to find out which thread is doing this, this is of course much more fun!

Using ps -p PID -f -L you’ll see the thread ID which is causing the problems. To relate this to a Python thread I subclass threading.Thread, override it’s .start() method to first wrap the .run() method so that you can log the thread ID before calling the original .run(). Since I was already doing all of this apart from the logging of the thread ID this was less work then it sounds. But the hard part is finding the thread ID.

Python knows of a threading.get_ident() method but this is merely a long unique integer and does not correspond to the actual thread ID of the OS. The kernel allows you to get the thread ID: getid(2). But this must be called using a system call with the constant name SYS_gettid. Because it’s hard to use constants in ctypes (at least I don’t know how to do this), and this is not portable anyway, I used this trivial C program to find out the constant value:

#include <stdio.h>
#include <sys/syscall.h>

int main(void)
{
    printf("%d\n", SYS_gettid);   // 输出 186
    printf("%d\n", SYS_getpid);   // 输出 39
    return 0;
}

In my case the constant to use is 186. Now all that is left is using ctypes to do the system call:

import ctypes

SYS_gettid = 186
libc = ctypes.cdll.LoadLibrary('libc.so.6')
tid = libc.syscall(SYS_gettid)

That’s it! Now you have the matching thread ID!

Going back to the original problem you can now associate this thread ID with the thread name and you should be able to find the problematic thread.

对于‘libc.so.6’的使用可以是直接调用或是先载入（Loadlibrary）都行。

2、采用ubuntu系统时可能会碰到libc.so.6位置的问题，即无法导入模块，或无法找到该动态库时解决方法：

在Ubuntu 14.04LTS用命令：/lib/libc.so.6时，提示” /lib/libc.so.6: not found“，其实这个库是存在的，只是地方换了，在"/lib/i386-linux-gnu/"下面，我们只需创建一个链接即可。使用下面的命令：

For 64 bit:
sudo ln -s /lib64/x86_64-linux-gnu/libc-2.13.so /lib64/libc.so.6

For 32 bit:
sudo ln -s /lib/i386-linux-gnu/libc-2.13.so /lib/libc.so.6

http://xiaorui.cc/2016/03/21/python%E4%B8%8B%E4%BD%BF%E7%94%A8ctypes%E8%8E%B7%E5%8F%96threading%E7%BA%BF%E7%A8%8Bid/

http://blog.51cto.com/happyliu/1731402