在平时工作中，经常会听到应用程序的进程和线程的概念，那么它们两个之间究竟有什么关系或不同呢？

一、对比进程和线程

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//task中会创建一个相应的目录，命名为其线程ID。由此在/proc//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]

(to connect to running process)

jstack -F [-m] [-l]

(to connect to a hung process)

jstack [-m] [-l]

(to connect to a core file)

jstack [-m] [-l] [server_id@]

(to connect to a remote debug server)

Options:

-F to force a thread dump. Use when jstack 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)

参考

线程查看

Android一个进程里面最少包含5个线程，分别为：

main线程(主线程)

FinalizerDaemon线程

终结者守护线程。对于重写了成员函数finalize的对象，它们被GC决定回收时，并没有马上被回收，而是被放入到一个队列中，等待FinalizerDaemon守护线程去调用它们的成员函数finalize，然后再被回收。

FinalizerWatchdogDaemon线程

监控终结者守护线程。用来监控FinalizerDaemon线程的执行。一旦检测那些重定了成员函数finalize的对象在执行成员函数finalize时超出一定的时候，那么就会退出VM。

HeapTaskDaemon线程

堆栈守护线程。用来执行堆栈的操作，也就是用来将那些空闲的堆内存归还给系统。

ReferenceQueueDaemon线程。

引用队列守护线程。我们知道，在创建引用对象的时候，可以关联一个队列。当被引用对象引用的对象被GC回收的时候，被引用对象就会被加入到其创建时关联的队列去。这个加入队列的操作就是由ReferenceQueueDaemon守护线程来完成的。这样应用程序就可以知道哪些被引用对象引用的对象已经被回收了。

下图是创建的一个仅有hello World！页面的工程，线程包含以下的这些。

image.png

刚开始我比较疑惑的是FileObserver 这个线程是否也是每个进程所必须包含的线程。后来我查看了一下Daemons创建的过程，能确定的是Android启动一个APP最少包含ReferenceQueueDaemon线程、FinalizerDaemon线程、FinalizerWatchdogDaemon线程、HeapTaskDaemon线程，以及在ActivityThread中开启的主线程。如下：

public final class Daemons {

private static final int NANOS_PER_MILLI = 1000 * 1000;

private static final int NANOS_PER_SECOND = NANOS_PER_MILLI * 1000;

private static final long MAX_FINALIZE_NANOS = 10L * NANOS_PER_SECOND;

public static void start() {

ReferenceQueueDaemon.INSTANCE.start();//开启ReferenceQueueDaemon线程

FinalizerDaemon.INSTANCE.start();//开启FinalizerDaemon线程

FinalizerWatchdogDaemon.INSTANCE.start();//开启FinalizerWatchdogDaemon线程

HeapTaskDaemon.INSTANCE.start();//开启HeapTaskDaemon线程

}

public static void startPostZygoteFork() {

ReferenceQueueDaemon.INSTANCE.startPostZygoteFork();

FinalizerDaemon.INSTANCE.startPostZygoteFork();

FinalizerWatchdogDaemon.INSTANCE.startPostZygoteFork();

HeapTaskDaemon.INSTANCE.startPostZygoteFork();

}

public static void stop() {

HeapTaskDaemon.INSTANCE.stop();

ReferenceQueueDaemon.INSTANCE.stop();

FinalizerDaemon.INSTANCE.stop();

FinalizerWatchdogDaemon.INSTANCE.stop();

}

...

}

1.main线程

2. ReferenceQueueDaemon线程。

代码块

3. FinalizerDaemon线程

private static class FinalizerDaemon extends Daemon {

private static final FinalizerDaemon INSTANCE = new FinalizerDaemon();

private final ReferenceQueue queue = FinalizerReference.queue;

private final AtomicInteger progressCounter = new AtomicInteger(0);

// Object (not reference!) being finalized. Accesses may race!

private Object finalizingObject = null;

FinalizerDaemon() {

super("FinalizerDaemon");

}

@Override public void runInternal() {

// This loop may be performance critical, since we need to keep up with mutator

// generation of finalizable objects.

// We minimize the amount of work we do per finalizable object. For example, we avoid

// reading the current time here, since that involves a kernel call per object. We

// limit fast path communication with FinalizerWatchDogDaemon to what's unavoidable: A

// non-volatile store to communicate the current finalizable object, e.g. for

// reporting, and a release store (lazySet) to a counter.

// We do stop the FinalizerWatchDogDaemon if we have nothing to do for a

// potentially extended period. This prevents the device from waking up regularly

// during idle times.

// Local copy of progressCounter; saves a fence per increment on ARM and MIPS.

int localProgressCounter = progressCounter.get();

while (isRunning()) {

try {

// Use non-blocking poll to avoid FinalizerWatchdogDaemon communication

// when busy.

FinalizerReference> finalizingReference = (FinalizerReference>)queue.poll();

if (finalizingReference != null) {

finalizingObject = finalizingReference.get();

progressCounter.lazySet(++localProgressCounter);

} else {

finalizingObject = null;

progressCounter.lazySet(++localProgressCounter);

// Slow path; block.

FinalizerWatchdogDaemon.INSTANCE.goToSleep();

finalizingReference = (FinalizerReference>)queue.remove();

finalizingObject = finalizingReference.get();

progressCounter.set(++localProgressCounter);

FinalizerWatchdogDaemon.INSTANCE.wakeUp();

}

doFinalize(finalizingReference);

} catch (InterruptedException ignored) {

} catch (OutOfMemoryError ignored) {

}

}

}

@FindBugsSuppressWarnings("FI_EXPLICIT_INVOCATION")

private void doFinalize(FinalizerReference> reference) {

FinalizerReference.remove(reference);

Object object = reference.get();

reference.clear();

try {

object.finalize();

} catch (Throwable ex) {

// The RI silently swallows these, but Android has always logged.

System.logE("Uncaught exception thrown by finalizer", ex);

} finally {

// Done finalizing, stop holding the object as live.

finalizingObject = null;

}

}

}

4. FinalizerWatchdogDaemon线程

代码块

5. HeapTaskDaemon线程

private static class HeapTaskDaemon extends Daemon {

private static final HeapTaskDaemon INSTANCE = new HeapTaskDaemon();

HeapTaskDaemon() {

super("HeapTaskDaemon");

}

// Overrides the Daemon.interupt method which is called from Daemons.stop.

public synchronized void interrupt(Thread thread) {

VMRuntime.getRuntime().stopHeapTaskProcessor();

}

@Override public void runInternal() {

synchronized (this) {

if (isRunning()) {

// Needs to be synchronized or else we there is a race condition where we start

// the thread, call stopHeapTaskProcessor before we start the heap task

// processor, resulting in a deadlock since startHeapTaskProcessor restarts it

// while the other thread is waiting in Daemons.stop().

VMRuntime.getRuntime().startHeapTaskProcessor();

}

}

// This runs tasks until we are stopped and there is no more pending task.

VMRuntime.getRuntime().runHeapTasks();

}

}

查看VMRuntime的源码发现 startHeapTaskProcessor()、runHeapTasks()均是native方法。

public native void requestConcurrentGC();

public native void concurrentGC();

public native void requestHeapTrim();

public native void trimHeap();

public native void startHeapTaskProcessor();

public native void stopHeapTaskProcessor();

public native void runHeapTasks();

如何查看当前项目包含几个线程

在Android studio中点击Profile 图标，点击 CPU，显示如下图，点击 Record，然后再点击 Stop，即可生成。

image.png