通过查看每个线程所占用的CPU时间

通过查看每个线程所占用的CPU时间缩小到具体线程，然后跟代码调试找到的。[喝小酒的网摘]http://blog.const.net.cn/a/17246.htm
在proc/pid/task下包含了该进程所有的线程，例如线程号2012,那么在proc/pid/task/2012/stat文件可以获取到此线程的信息，其中第14个域和15个于就是用户态时间和内核态时间，依据这2个时间就能知道CPU到底花在哪个线程中了。

注意stat显示为空文件，使用tail -f stat查看即可。

Linux proc/pid/task/tid/stat文件详解 

[root@localhost ~]# cat /proc/6873/stat
6873 (a.out) R 6723 6873 6723 34819 6873 8388608 77 0 0 0 41958 31 0 0 25 0 3 0 5882654 1409024 56 4294967295 134512640 134513720 3215579040 0 2097798 0 0 0 0 0 0 0 17 0 0 0 [root@localhost ~]#

每个参数意思为：
参数                                                       解释
pid=6873                                              进程(包括轻量级进程，即线程)号
comm=a.out                                          应用程序或命令的名字
task_state=R                                        任务的状态，R:runnign, S:sleeping (TASK_INTERRUPTIBLE), D:disk sleep (TASK_UNINTERRUPTIBLE), T: stopped, T:tracing stop,Z:zombie, X:dead
ppid=6723                                            父进程ID
pgid=6873                                            线程组号
sid=6723                                              该任务所在的会话组ID
tty_nr=34819(pts/3)                            该任务的tty终端的设备号，INT（34817/256）=主设备号，（34817-主设备号）=次设备号
tty_pgrp=6873                                     终端的进程组号，当前运行在该任务所在终端的前台任务(包括shell 应用程序)的PID。
task->flags=8388608                           进程标志位，查看该任务的特性
min_flt=77                                            该任务不需要从硬盘拷数据而发生的缺页（次缺页）的次数
cmin_flt=0                                            累计的该任务的所有的waited-for进程曾经发生的次缺页的次数目
maj_flt=0                                              该任务需要从硬盘拷数据而发生的缺页（主缺页）的次数
cmaj_flt=0                                            累计的该任务的所有的waited-for进程曾经发生的主缺页的次数目
utime=1587                                          该任务在用户态运行的时间，单位为jiffies
stime=1                                                该任务在核心态运行的时间，单位为jiffies
cutime=0                                              累计的该任务的所有的waited-for进程曾经在用户态运行的时间，单位为jiffies
cstime=0                                              累计的该任务的所有的waited-for进程曾经在核心态运行的时间，单位为jiffies
priority=25                                           任务的动态优先级
nice=0                                                  任务的静态优先级
num_threads=3                                    该任务所在的线程组里线程的个数
it_real_value=0                                     由于计时间隔导致的下一个 SIGALRM 发送进程的时延，以 jiffy 为单位.
start_time=5882654                             该任务启动的时间，单位为jiffies
vsize=1409024（page）                       该任务的虚拟地址空间大小
rss=56(page)                                        该任务当前驻留物理地址空间的大小
Number of pages the process has in real memory,minu 3 for administrative purpose.
这些页可能用于代码，数据和栈。
rlim=4294967295（bytes）                  该任务能驻留物理地址空间的最大值
start_code=134512640                        该任务在虚拟地址空间的代码段的起始地址
end_code=134513720                         该任务在虚拟地址空间的代码段的结束地址
start_stack=3215579040                     该任务在虚拟地址空间的栈的结束地址
kstkesp=0                                            esp(32 位堆栈指针) 的当前值, 与在进程的内核堆栈页得到的一致.
kstkeip=2097798                                 指向将要执行的指令的指针, EIP(32 位指令指针)的当前值.
pendingsig=0                                       待处理信号的位图，记录发送给进程的普通信号
block_sig=0                                          阻塞信号的位图
sigign=0                                               忽略的信号的位图
sigcatch=082985                                  被俘获的信号的位图
wchan=0                                               如果该进程是睡眠状态，该值给出调度的调用点
nswap                                                   被swapped的页数，当前没用
cnswap                                                 所有子进程被swapped的页数的和，当前没用
exit_signal=17                                      该进程结束时，向父进程所发送的信号
task_cpu(task)=0                                  运行在哪个CPU上
task_rt_priority=0                                 实时进程的相对优先级别
task_policy=0                                        进程的调度策略，0=非实时进程，1=FIFO实时进程；2=RR实时进程

[喝小酒的网摘]http://blog.const.net.cn/a/17246.htm

转载自 [blog.const.net.cn]喝小酒的网摘 及本文链接地址:http://blog.const.net.cn/a/17246.htm

相关文章

Linux多线程程序死循环问题调试软件在某个时刻停止服务，CPU占用达到100%+，这种问题一个可能的原因是产生了死循环，假设程序某处存在潜在的死循环，并在某种条件下会引发，本文以一个示例来定位出现死循环的位置。
当 程序某处存在死循环，通常定位问题及缩小范围的方法是，在可疑的代码处加log，或者注释掉可疑代码，这对于容易重现问题的程序来说还好，但对于“偶尔” 才会产生问题程序却很难调试，因为

linux pthread_self 使用#include <pthread.h> 
#include <stdio.h>
int main() 
{ 
pid_t pid; 
pthread_t tid; 
pid = getpid(); 
tid = pthread_self(); 
printf(&

linux多线程下获得线程ID需要在程序一个线程中获得这个线程的id，有人会说，可以通过pthread_create函数传递参数传入，等主线程创建子线程成功，那么这个pid会自动赋值
#define TNUM 2
struct BN
{
    pthread_t pid;
    int N;<b< span="">

Linux中多线程下gettid()的使用因为gettid()是Linux他自己的，因此把里面实现函数拷贝出来，写到自己的程序里即可。头文件有
<sys/syscall.h>
实现代码如下：

pid_t gettid() 
{      

linux gettid获取线程id经常会用到gettid()，来获取线程号，判断问题出在哪个线程里面。

如出现诸如这样的error： undefined reference to `gettid' 我们可以自已定义实现方法，如下： #include <sys/syscall.h> /*此头必须带上*/ pid_t gettid()
{