在平時工作中，經常會聽到應用程序的進程和線程的概念，那么它們兩個之間究竟有什么關系或不同呢？
一、對比進程和線程
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 cached
PID 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
47
3）通過查看/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 ~]# uptime
10: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 cached
PID 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 nginx
2148 ? 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)