日韩性视频-久久久蜜桃-www中文字幕-在线中文字幕av-亚洲欧美一区二区三区四区-撸久久-香蕉视频一区-久久无码精品丰满人妻-国产高潮av-激情福利社-日韩av网址大全-国产精品久久999-日本五十路在线-性欧美在线-久久99精品波多结衣一区-男女午夜免费视频-黑人极品ⅴideos精品欧美棵-人人妻人人澡人人爽精品欧美一区-日韩一区在线看-欧美a级在线免费观看

歡迎訪問 生活随笔!

生活随笔

當前位置: 首頁 > 编程资源 > 编程问答 >内容正文

编程问答

如何查询一个进程下面的线程数(进程和线程区别)

發布時間:2024/6/21 编程问答 32 豆豆
生活随笔 收集整理的這篇文章主要介紹了 如何查询一个进程下面的线程数(进程和线程区别) 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

?

在平時工作中,經常會聽到應用程序的進程和線程的概念,那么它們兩個之間究竟有什么關系或不同呢?

一、對比進程和線程

1)兩者概念
-? 進程是具有一定獨立功能的程序關于某個數據集合上的一次運行活動,進程是系統進行資源分配和調度的一個獨立單位.
-? 線程是指進程內的一個執行單元,也是進程內的可調度實體. 線程是CPU調度和分派的基本單位,它是比進程更小的能獨立運行的基本單位線程自己基本上不擁有系統資源,只擁有一點在運行中必不可少的資源(如程序計數器,一組寄存器和棧),但是它可與同屬一個進程的其他的線程共享進程所擁有的全部資源.

2)兩者關系
-? 一個線程可以創建和撤銷另一個線程;同一個進程中的多個線程之間可以并發執行.
-? 相對進程而言,線程是一個更加接近于執行體的概念,它可以與同進程中的其他線程共享數據,但擁有自己的棧空間,擁有獨立的執行序列。

3)兩者區別
-? 進程和線程的主要差別在于它們是不同的操作系統資源管理方式:進程有獨立的地址空間,一個進程崩潰后,在保護模式下不會對其它進程產生影響;而線程只是一個進程中的不同執行路徑。
-? 線程有自己的堆棧和局部變量,但線程之間沒有單獨的地址空間,一個線程死掉就等于整個進程死掉,所以多進程的程序要比多線程的程序健壯,但在進程切換時,耗費資源較大,效率要差一些.?但對于一些要求同時進行并且又要共享某些變量的并發操作,只能用線程,不能用進程。

進程和線程的區別
-? 地址空間:線程是進程內的一個執行單元;進程至少有一個線程;它們共享進程的地址空間;而進程有自己獨立的地址空間;
-? 資源擁有:進程是資源分配和擁有的單位,同一個進程內的線程共享進程的資源
-? 線程是處理器調度的基本單位,但進程不是.
-? 進程和線程二者均可并發執行.
-? 簡而言之,一個程序至少有一個進程,一個進程至少有一個線程.
-? 線程的劃分尺度小于進程,使得多線程程序的并發性高。
-? 另外,進程在執行過程中擁有獨立的內存單元,而多個線程共享內存,從而極大地提高了程序的運行效率。
-? 線程在執行過程中與進程是有區別的。每個獨立的線程有一個程序運行入口、順序執行序列和程序的出口。但是線程不能夠獨立執行,必須依存在應用程序中,由應用程序提供多個線程執行控制。
-? 從邏輯角度來看,多線程的意義在于一個應用程序中,有多個執行部分可以同時執行。但操作系統并沒有將多個線程看做多個獨立的應用,來實現進程的調度和管理以及資源分配。這就是進程和線程的重要區別。

4)優缺點
線程和進程在使用上各有優缺點:
-? 線程執行開銷小,但不利于資源的管理和保護;而進程正相反。
-? 線程適合于在SMP機器上(即對稱多處理結構的簡稱,是指在一個計算機上匯集了一組處理器(多CPU),各CPU之間共享內存子系統以及總線結構)運行,而進程則可以跨機器遷移。

二、如何查看某個進程的線程數

有些時候需要確定進程內部當前運行了多少線程,查詢方法如下:1)通過pstree命令(根據pid)進行查詢: [root@xqsj_web2 ~]# ps -ef|grep java //查找進程pid(比如這里查找java(tomcat)進程的pid) [root@xqsj_web2 ~]# pstree -p 19135 java(19135)─┬─{java}(19136)├─{java}(19137).......└─{java}(13578) [root@xqsj_web2 ~]# pstree -p 19135|wc -l 46 //由于第一行包括了2個線程,所以該進程下一共有47個線程!或者使用top命令查看(可以查看到線程情況) [root@xqsj_web2 ~]# top -Hp 19135 //下面結果中的Tasks 對應的47即是線程的個數top - 14:05:55 up 391 days, 20:59, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 47 total, 0 running, 47 sleeping, 0 stopped, 0 zombie Cpu(s): 0.2%us, 0.1%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8058056k total, 7718656k used, 339400k free, 354216k buffers Swap: 0k total, 0k used, 0k free, 4678160k cachedPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19135 root 20 0 5339m 632m 5476 S 0.0 8.0 0:00.00 java 19136 root 20 0 5339m 632m 5476 S 0.0 8.0 0:00.84 java ......2)根據ps命令直接查詢: [root@xqsj_web2 ~]# ps hH p 19135| wc -l 473)通過查看/proc/pid/status proc偽文件系統,它駐留在/proc目錄,這是最簡單的方法來查看任何活動進程的線程數。/proc目錄以可讀文本文件形式輸出,提供現有進程和系統硬件 相關的信息如CPU、中斷、內存、磁盤等等。[root@xqsj_web2 ~]# cat /proc/19135/status Name: java State: S (sleeping) Tgid: 19135 Pid: 19135 PPid: 1 TracerPid: 0 ........ Threads: 47 //這里顯示的是進程創建的總線程數。輸出表明該進程有47個線程。 SigQ: 1/62793 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 ....... voluntary_ctxt_switches: 1 nonvoluntary_ctxt_switches: 1或者,也可以在/proc//task中簡單的統計子目錄的數量,如下所示: [root@xqsj_web2 ~]# ll /proc/19135/task 總用量 0 dr-xr-xr-x 6 root root 0 6月 14 17:57 11553 ...... [root@xqsj_web2 ~]# ll /proc/19135/task|wc -l 48這是因為,對于一個進程中創建的每個線程,在/proc/<pid>/task中會創建一個相應的目錄,命名為其線程ID。由此在/proc/<pid>/task中目錄的總數表示在進程中線程的數目。

比如某臺服務器的CPU使用率飆升,通過top命令查看是gitlab程序占用的cpu比較大,"ps -ef|grep gitlab"發現有很多個gitlab程序,現在需要查詢gitlab各個進程下的線程數情況。批量查詢命令如下:
# for pid in $(ps -ef|grep -v grep|grep gitlab|awk '{print $2}');do echo ${pid} > /root/a.txt ;cat /proc/${pid}/status|grep Threads > /root/b.txt;paste /root/a.txt /root/b.txt;done|sort -k3 -rn

腳本解釋:

1)for pid in $(ps -ef|grep -v grep|grep gitlab|awk '{print $2}') 定義${pid}變量為gitlab進程的pid號2)echo ${pid} > /root/a.txt 將http進程的pid號都打印到/root/a.txt文件中3)cat /proc/${pid}/status|grep Threads > /root/b.txt 將各個pid進程號下的線程信息打印到/root/b.txt文件中4)paste /root/a.txt /root/b.txt 以列的形式展示a.txt和b/txt文件中的信息5)sort -k3 -rn -k3 表示以第三列進行排序 -rn 表示降序

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?來看個cup使用率告警問題處理案例? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

收到告警,生產環境一臺機器的cpu使用率超過了85%!立刻登錄服務器,發現情況如下: [root@kevin ~]# uptime10:39:40 up 215 days, 13:02, 2 users, load average: 3.32, 3.40, 3.37[root@kevin ~]# top top - 10:52:51 up 215 days, 13:15, 3 users, load average: 3.32, 3.40, 3.37 Tasks: 168 total, 1 running, 167 sleeping, 0 stopped, 0 zombie Cpu(s): 98.4%us, 0.2%sy, 0.0%ni, 1.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8053692k total, 6542296k used, 1511396k free, 168560k buffers Swap: 16777212k total, 0k used, 16777212k free, 2565452k cachedPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31969 app 20 0 4510m 1.9g 6220 S 393.5 25.1 2281:49 java .........[root@kevin ~]# ps -ef|grep 31969 root 15826 15129 0 10:58 pts/0 00:00:00 grep 31969 app 31969 31962 0 Jul02 ? 02:25:01 java -cp /data/lo-boxes/box_home/lo-starter.jar:/data/lo-boxes/box_home/lib/* -Dbox.name=B0002 -Dbox.home=/data/lo-boxes/B0002 -Dbox.jmx.port=57009 -XX:+CMSPermGenSweepingEnabled -XX:SoftRefLRUPolicyMSPerMB=1 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=60 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=1 -XX:+CMSClassUnloadingEnabled -XX:MaxTenuringThreshold=12 -XX:SurvivorRatio=8 -XX:ParallelGCThreads=3 -XX:+HeapDumpOnOutOfMemoryError -Dsun.reflect.inflationThreshold=2147483647 -XX:HeapDumpPath=/data/lo-boxes/B0002/boxlogs/logs/heapdump_31961.hprof -Xloggc:/data/lo-boxes/B0002/boxlogs/gclogs/gc.31961.log -XX:ErrorFile=/data/lo-boxes/B0002/boxlogs/hs_err_pid31961.log -Xms1024M -Xmx1024M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:NewSize=256M -XX:MaxNewSize=512M cn.openlo.starter.BoxStartupStandalone解決辦法: 1)最簡單粗暴的方法:重啟上面這個pid號為31969的進程所屬的服務程序 2)查出這個pid進程的cpu資源各自被哪個線程所占。通過"top -Hp pid"可以查看該進程下各個線程的cpu使用情況;如下: [root@kevin ~]# top -Hp 31969 .......PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31969 app 20 0 3754m 1714m 16m S 390.5 29.1 0:00.00 java 31970 app 20 0 3754m 2124m 16m S 382.2 20.5 0:02.74 java 31971 app 20 0 3754m 1954m 16m S 360.0 19.5 0:00.49 java 31972 app 20 0 3754m 1584m 16m S 300.9 23.1 0:00.48 java ......如上可知,31969的進程主要被上面四個線程耗了過多的CPU資源。通過top命令定位到cpu占用率較高的線程之后,繼續使用jstack pid命令查看當前java進程的堆棧狀態,這就用到jstack工具! jstack是java虛擬機自帶的一種堆棧跟蹤工具。jstack用于打印出給定的java進程ID或core file或遠程調試服務的Java堆棧信息。 jstack可以定位到線程堆棧,根據堆棧信息我們可以定位到具體代碼,所以它在JVM性能調優中使用得非常多。jstack工具一般是在java/bin目錄下的。如下設置java環境變量 ============================================================================================= [root@kevin ~]# ll /data/software/ 總用量 626244 drwxr-xr-x 8 app app 4096 4月 11 2015 jdk1.7.0_80 -rw-r--r-- 1 app app 153530841 6月 4 2016 jdk-7u80-linux-x64.tar.gz [root@kevin ~]# /data/software/jdk1.7.0_80/bin/java -version java version "1.7.0_80" Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)[root@kevin ~]# vim /etc/profile JAVA_HOME=/data/software/jdk1.7.0_80 JAVA_BIN=/data/software/jdk1.7.0_80/bin PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/bin:/sbin/:/data/software/jdk1.7.0_80/bin/ CLASSPATH=.:/lib/dt.jar:/lib/tools.jar export JAVA_HOME JAVA_BIN PATH CLASSPATH[root@kevin ~]# source /etc/profile [root@kevin ~]# mv /usr/bin/java /usr/bin/java.bak [root@kevin ~]# ln -s /data/software/jdk1.7.0_80/bin/java /usr/bin/java[root@kevin ~]# java -version java version "1.7.0_80" Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)[root@kevin ~]# jstack --help Usage:jstack [-l] <pid>(to connect to running process)jstack -F [-m] [-l] <pid>(to connect to a hung process)jstack [-m] [-l] <executable> <core>(to connect to a core file)jstack [-m] [-l] [server_id@]<remote server IP or hostname>(to connect to a remote debug server)Options:-F to force a thread dump. Use when jstack <pid> does not respond (process is hung)-m to print both java and native frames (mixed mode)-l long listing. Prints additional information about locks-h or -help to print this help message =============================================================================================下面開始使用jstack對 [root@kevin ~]# jstack 31969 或者"jstack 31969 > jstack-31969" 打印出堆棧信息到一個文件中,方便后續查看 [root@kevin ~]# jstack 31970 [root@kevin ~]# jstack 31971 [root@kevin ~]# jstack 31972

jstack命令生成的thread dump信息包含了JVM中所有存活的線程,為了分析指定線程,必須找出對應線程的調用棧,應該如何找?

在top命令中,已經獲取到了占用cpu資源較高的線程pid,將該pid轉成16進制的值,在thread dump中每個線程都有一個nid,找到對應的nid即可;隔段時間再執行一次stack命令獲取thread dump,區分兩份dump是否有差別,在nid=0x246c的線程調用棧中,發現該線程一直在執行JstackCase類第33行的calculate方法,得到這個信息,就可以檢查對應的代碼是否有問題。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

獲取進程pid的方法 [root@ansible-server ~]# ps -ef|grep nginx root 2148 1 0 2018 ? 00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf root 16517 16179 0 11:09 pts/1 00:00:00 grep nginx nginx 21091 2148 0 Jan27 ? 00:00:00 nginx: worker process 使用"ps x" [root@ansible-server ~]# ps x | grep nginx2148 ? Ss 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf 16526 pts/1 S+ 0:00 grep nginx[root@ansible-server ~]# ps x | grep nginx|grep -v grep|awk '{print $1}' 2148使用"pgrep" [root@ansible-server ~]# pgrep nginx 2148 21091[root@ansible-server ~]# pgrep -f nginx 2148 21091使用pidof [root@ansible-server ~]# pidof nginx 21091 2148使用pstree [root@ansible-server ~]# pstree -p | grep nginx|-nginx(2148)---nginx(21091)

轉載于:https://www.cnblogs.com/kevingrace/p/5252919.html

總結

以上是生活随笔為你收集整理的如何查询一个进程下面的线程数(进程和线程区别)的全部內容,希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯,歡迎將生活随笔推薦給好友。