多线程就一定比单线程快吗？

为什么要使用多线程？

在探讨文章题目之前，我们先来思考这样一个问题，你为什么要使用多线程？我相信很多人在遇到这个问题时会不假思索的回答出答案，因为并发快，那为什么并发快呢？

对于多核 CPU 来说，每个物理核心都能独立执行任务，这种条件下，使用并发技术（准确的来说这里可以称之为并行，因为多核）当然合情合理。但是我们来想想对于单核的 CPU ，为什么操作系统还要引入多线程技术呢？或者说是我们的程序为何要利用多线程技术呢？

设想一下这样的一个场景，我们现在的程序是单线程的，而且代码中充斥着大量的读取文件内容的操作，而我们知道，硬盘的读写速度与内存差好几个数量级，那么进行 IO 时就不得不阻塞，等待 IO 的完成。那等待 IO 的时候，CPU 在干啥呢？没错，CPU 在发呆，因为我们的程序是单线程的，换句话说，程序是串行执行的，在任何地方发生了阻塞，都将导致无法进行其他任何的工作。

线程阻塞时，CPU 在那愣着，那么 CPU 就没有得到充分的利用，而造成资源浪费。而使用多线程，就是出于尽量榨干 CPU 的思想，将任务拆分，由不同的线程去完成被拆分的部分，这样就算遇到我之前所说的，需要等待的情况，那么随着该线程时间片的耗尽，别的线程也不会让 CPU 在那发呆。

综上，使用多线程的很大一部分原因在于，当某个线程阻塞时，让别的工作能够正常执行，比如，现在的 Web 应用程序，如果是单线程的话，对于请求的处理，那就只能一个一个的处理，如果有个请求在处理的时候阻塞了，那行了，后边的都等着吧。这样的网站，相信过不了两天就得 GG。而且对于现在的网络应用程序很多都是 IO 密集型的任务，使用多线程技术就变得更加的无可厚非了。

多线程就必定比单线程快？

说回文章正题，并发就是银弹吗？能保证性能一定比单线程好？

我们来看一个简单的测试用例。这是一个简单的对两个数进行累加和递减的代码，其中对于并发的测试，我们将累加和递减交由两个线程来完成。而对于串行的测试，我们将在一个线程内完成这两个操作。

package FirstChapter;

public class ConcurrencyTest {
	
	private static final long count = 10000;
	

	public static void main(String[] args) throws InterruptedException {
		
		System.out.println("当前操作次数为：" + count);
		//并发执行
		concurrency();
		//串行执行
		serial();
	}
	
	//并发执行，a的累加操作由另外一个线程执行，b的递减操作依然后主线程来执行
	private static void concurrency() throws InterruptedException {
		long start = System.currentTimeMillis();
		Thread thread = new Thread(new Runnable() {
			@Override
			public void run() {
				long a = 0;
				for(int i = 0;i < count;i++)
					a += 5;
			}
		});
		thread.start();
		long b = 0;
		for(int j = 0;j < count;j ++)
			b--;
		//将对a的累加的任务交由另外的线程执行
		thread.join();
		long time = System.currentTimeMillis() - start;
		System.out.println("并发执行耗时:"+time+"ms");
	}
	
	//串行执行，a的累加操作和b递减操作都由主线程来执行
	private static void serial() {
		long start = System.currentTimeMillis();
		long a = 0;
		for(int i = 0; i < count; i++) {
			a += 5;
		}
		long b = 0;
		for(int i = 0;i < count; i++) {
			b--;
		}
		long spend = System.currentTimeMillis() - start;
		System.out.println("串行耗时:"+spend+"ms");
	}

}