并发编程的目的是为了让程序运行得更快，但是，并不是启动更多的线程就能让程序最大限度地并发执行。在并发编程时，如果希望通过多线程执行任务让程序运行得更快，会面临非常多的挑战，比如：上下文的切换问题、死锁问题、以及受限制于硬件和软件资源限制问题。
上下文切换
即使单核处理器也支持多线程执行代码，CPU通过给每个线程分配CPU时间片来实现这个机制。时间片是CPU分配给各个线程的时间，因为时间片非常短，所以CPU通过不停切换线程执行，让我们感觉多个线程是同时执行的，时间片一般是几十毫秒。
CPU通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个任务。但是，在切换前会保存上一个任务的状态，以便下次切换回这个任务时，可以再加载这个任务的状态。所以任务从保存到再加载的过程就是一次上下文切换。 从系统的角度理解上下文切换请移步至这篇文章<<Linux进程管理>>。
多线程一定快？
下面的代码并发执行一定比串行快吗？
public class ConcurrencyTest {
private static final long count = 10000 * 1000l;
public static void main(String[] args) throws InterruptedException {
concurrency();
serial();
}
private static void concurrency() throws InterruptedException {
long start = System.currentTimeMillis();
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
int a = 0;
for (int i = 0; i < count; i++) {
a += 5;
}
}
});
thread.start();
int b = 0;
for (long i = 0; i < count; i++) {
b--;
}
long time = System.currentTimeMillis() - start;
thread.join();
System.out.printf("concurrency: %d ms,b=%d \n", time, b);
}
private static void serial() {
long start = System.currentTimeMillis();
int a = 0;
for (int i = 0; i < count; i++) {
a += 5;
}
int b = 0;
for (int i = 0; i < count; i++) {
b--;
}
long time = System.currentTimeMillis() - start;
System.out.printf("serial: %d ms,a=%d, b=%d \n", time, a, b);
}
}
测试结果表明：并发不一定比串行快，当并发执行累加操作不超过100万次时，速度会比串行累加操作要慢。这是因为线程有创建和上下文切换的开销。
测试上下文切换次数和时长
- 使用Lmbench3可以测量上下文切换的时长
- 使用vmstat可以测量上下文切换的次数
vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 13195448 182308 4539940 0 0 0 731 1 1 3 2 94 1 0 2 0 0 13195936 182308 4540052 0 0 0 0 12681 32658 1 1 98 0 0 0 0 0 13195960 182308 4540164 0 0 0 0 12578 32297 2 1 98 0 0 1 0 0 13195736 182308 4540280 0 0 0 48 12892 33908 2 1 97 0 0 0 0 0 13195984 182308 4540384 0 0 0 4 12602 32801 1 1 98 0 0 2 0 0 13159652 182308 4576968 0 0 0 0 13576 34423 5 1 94 0 0 0 0 0 12983152 182308 4754012 0 0 0 0 13622 33814 5 2 93 0 0
CS(Content Switch)表示上下文切换的次数，从数据中可以看到上下1秒切换1W多次。
如何减少上下文切换
减少上下文切换的方法有: 无锁并发编程、CAS算法、使用最少线程和协程。
- 无锁并发编程：多线程竞争锁时，会引起上下文切换，所以多线程处理数据时，可以一些办法来避免使用锁，比如将数据的ID按照Hash算法取模分段，不同的线程处理不同段的数据。
- CAS算法：Java的Atomic包使用CAS算法来更新数据，而不需要加锁。
- 使用最小线程：避免创建不需要的线程，比如任务很少，但是创建了很多的线程来处理，这样会造成大量的线程处于等待状态。
- 协程：在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换。
通过jstack查看线程状态，如果有大量WAITING状态的线程，减少线程数达到减少上下文切换。
jstack 3616 |grep "java.lang.Thread.State" |awk '{print $2$3$4$5}'|sort | uniq -c
16 RUNNABLE
6 TIMED_WAITING(parking)
4 WAITING(onobjectmonitor)
2 WAITING(parking)
LMbench：http://www.bitmover.com/lmbench/
死锁
锁是一个非常有用的工具，运用场景非常多，因为它使用起来非常简单，而且易于理解。但同时它也会带来一些困扰，那就是可能会引起死锁，一旦产生死锁，就会造成系统功能不可用。下面的代码就会产生死锁。
public class DeadLockDemo {
private static String A = "A";
private static String B = "B";
public static void main(String[] args) throws InterruptedException {
new DeadLockDemo().deadLock();
}
private void deadLock() throws InterruptedException {
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
synchronized (A) {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (B) {
System.out.println("x");
}
}
}
});
Thread t2 = new Thread(new Runnable() {
@Override
public void run() {
synchronized (B) {
synchronized (A) {
System.out.println("y");
}
}
}
});
t1.start();
t2.start();
}
}
死锁的堆栈信息
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode):
"DestroyJavaVM" #12 prio=5 os_prio=0 tid=0x0000000001c8d800 nid=0x27e8 waiting o
n condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Thread-1" #11 prio=5 os_prio=0 tid=0x0000000016508000 nid=0x2e34 waiting for mo
nitor entry [0x00000000175ff000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.javagc.art.chapter1.DeadLockDemo$2.run(DeadLockDemo.java:34)
- waiting to lock <0x00000000eb2fe9b0> (a java.lang.String)
- locked <0x00000000eb2fe9e0> (a java.lang.String)
at java.lang.Thread.run(Unknown Source)
"Thread-0" #10 prio=5 os_prio=0 tid=0x0000000016507800 nid=0x2d28 waiting for mo
nitor entry [0x00000000173af000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.javagc.art.chapter1.DeadLockDemo$1.run(DeadLockDemo.java:24)
- waiting to lock <0x00000000eb2fe9e0> (a java.lang.String)
- locked <0x00000000eb2fe9b0> (a java.lang.String)
at java.lang.Thread.run(Unknown Source)
"Service Thread" #9 daemon prio=9 os_prio=0 tid=0x00000000164a3800 nid=0x2b20 ru
nnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C1 CompilerThread2" #8 daemon prio=9 os_prio=2 tid=0x0000000016440000 nid=0x27b
c waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread1" #7 daemon prio=9 os_prio=2 tid=0x000000001643a800 nid=0x2be
8 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x0000000016435800 nid=0x2a4
c waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x0000000016433000 nid=0x2b34 w
aiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x0000000014f8f000 nid=0x2bc4
runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x0000000014f23000 nid=0x2874 in Obje
ct.wait() [0x000000001641f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000eb206f58> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- locked <0x00000000eb206f58> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(Unknown Source)
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000014f21800 nid=0x262
4 in Object.wait() [0x0000000015f7f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000eb206998> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Unknown Source)
at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
- locked <0x00000000eb206998> (a java.lang.ref.Reference$Lock)
"VM Thread" os_prio=2 tid=0x0000000014f1c000 nid=0x27c0 runnable
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x000000000234c000 nid=0x2714 runn
able
"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x000000000234d800 nid=0x2b3c runn
able
"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000000000234f000 nid=0x2ee0 runn
able
"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000002352800 nid=0x215c runn
able
"VM Periodic Task Thread" os_prio=2 tid=0x00000000164c1000 nid=0x2df0 waiting on
condition
JNI global references: 6
Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor 0x0000000014f28328 (object 0x00000000eb2fe9b0, a java.
lang.String),
which is held by "Thread-0"
"Thread-0":
waiting to lock monitor 0x0000000014f297c8 (object 0x00000000eb2fe9e0, a java.
lang.String),
which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":
at com.javagc.art.chapter1.DeadLockDemo$2.run(DeadLockDemo.java:34)
- waiting to lock <0x00000000eb2fe9b0> (a java.lang.String)
- locked <0x00000000eb2fe9e0> (a java.lang.String)
at java.lang.Thread.run(Unknown Source)
"Thread-0":
at com.javagc.art.chapter1.DeadLockDemo$1.run(DeadLockDemo.java:24)
- waiting to lock <0x00000000eb2fe9e0> (a java.lang.String)
- locked <0x00000000eb2fe9b0> (a java.lang.String)
at java.lang.Thread.run(Unknown Source)
Found 1 deadlock.
避免死锁几个常见方法：
- 避免一个线程同时获取多个锁
- 避免一个线程在锁内同时占用多个资源，尽量保证每个锁只占用一个资源
- 尝试使用定时锁，使用lock.tryLock(timeout)来替代使用内部锁机制。
- 对于数据库锁，加锁和解锁必须在一个数据库连接里，否则会出现解锁失败的情况。