性能优化——如何优化多线程上下文切换

如果是单个线程，在CPU 调用之后，那么它基本上是不会被调度出去的。如果可运行的线程数远大于 CPU 数量，那么操作系统最终会将某个正在运行的线程调度出来，从而使其它线程能够使用 CPU，这就会导致上下文切换。

 

还有，在多线程中如果使用了竞争锁，当线程由于等待竞争锁而被阻塞时，JVM 通常会将这个锁挂起，并允许它被交换出去。如果频繁地发生阻塞，CPU 密集型的程序就会发生更多的上下文切换。

 

那么问题来了，我们知道在某些场景下使用多线程是非常必要的，但多线程编程给系统带来了上下文切换，从而增加的性能开销也是实打实存在的。那么我们该如何优化多线程上下文切换呢？这就是我今天要和你分享的话题，我将重点介绍几种常见的优化方法。

 

竞争锁优化

 

大多数人在多线程编程中碰到性能问题，第一反应多是想到了锁。

 

多线程对锁资源的竞争会引起上下文切换，还有锁竞争导致的线程阻塞越多，上下文切换就越频繁，系统的性能开销也就越大。由此可见， 在多线程编程中，锁其实不是性能开销的根源，竞争锁才是。

 

前面集中讲过锁优化，我们知道锁的优化归根结底就是减少竞争。这讲中我们就再来总结下锁优化的一些方式。

 

1. 减少锁的持有时间

 

我们知道，锁的持有时间越长，就意味着有越多的线程在等待该竞争资源释放。如果是 Synchronized 同步锁资源，就不仅是带来线程间的上下文切换，还有可能会增加进程间的上下文切换。

 

在前面，我曾分享过一些更具体的方法，例如，可以将一些与锁无关的代码移出同步代码块，尤其是那些开销较大的操作以及可能被阻塞的操作。

 

优化前

 

 

public synchronized void mySyncMethod(){

businesscode1();

mutextMethod();

businesscode2();

}

 

优化后

 

public void mySyncMethod(){

businesscode1();

synchronized(this)

{

mutextMethod();

}

businesscode2();

}

 

2. 降低锁的粒度

 

同步锁可以保证对象的原子性， 我们可以考虑将锁粒度拆分得更小一些，以此避免所有线程对一个锁资源的竞争过于激烈。 具体方式有以下两种：

 

锁分离

 

与传统锁不同的是，读写锁实现了锁分离，也就是说读写锁是由“读锁”和“写锁”两个锁实现的，其规则是可以共享读，但只有一个写。