性能调优之上下文切换

极客时间，java性能调优 学习笔记

（1）TCP 长连接 +Protobuf 序列化实现的RPC，性能要明显优于短连接的 Http+Json 序列化的RPC性能；

（2）偏向锁主要用来优化同一线程多次申请同一个锁的竞争，当一个线程再次访问这个同步代码或方法时，该线程只需去对象头的 Mark Word 中去判断一下是否有偏向锁指向它的 ID，无需再进入 Monitor 去竞争对象了；

（3）Lock 锁的基本操作是通过乐观锁来实现的，但由于 Lock 锁也会在阻塞时被挂起，因此它依然属于悲观锁；

（4）不管使用 Synchronized 同步锁还是 Lock 同步锁，只要存在锁竞争就会产生线程阻塞，从而导致线程之间的频繁切换，最终增加性能消耗。因此，如何降低锁竞争，就成为了优化锁的关键。

（5）在高并发下，由于CPU存在上下文切换，对于逻辑很复杂、等待时间较长或需要大量计算的场景，使用多线程来提高系统的整体性能；对于单个逻辑比较简单，而且速度速度相对来非常快的情况，使用单线程更好;

（6）在linux操作系统中，进程的运行空间一般分为用户态和内核态，用户态空间一般是进程应用运行空间，而内核态空间一般是指应用需要调用系统资源，应用不能再用户态空间直接调用系统资源，需要通过内核态来系统系统资源。

（7）使用Synchronized获得锁失败，将会从用户态到内核态的切换，发生进程上下文切换。如果竞争锁时Synchronized锁升级或降级，也会发生上下文切换；

（8）sleep不会释放锁资源，wait则会，但两者都会从running状态中走出，不再占用CPU资源。

（9）在多线程编程中，锁其实不是性能开销的根源，竞争锁才是；

（10）同步锁可以保证对象的原子性，可将锁粒度拆分得更小一些，以此避免所有线程对一个锁资源的竞争过于激烈。如采用锁分离，读读是不互斥的，在读远大于写的多线程场景中避免了上下文切换；采用锁分段进一步分解，如ConcurrentHashMap；

（11）线程池的线程数量设置不宜过大，工作线程总数超过系统所拥有的处理器数量会导致过多的上下文切换；

（12）多个消费者线程同时被阻塞，用 notifyAll() 方法会唤醒所以处于阻塞状态的消费者线程，过早地唤醒导致线程再次进入阻塞状态，引起上下文切换。