《java performance》读书笔记之java应用调优tips

        首先 java performance把应用中代码引起的性能问题分为以下几类：
         1.低效的算法、数据结构
         2.锁竞争

         3.低效的代码

         然后文章分门别类得列举了一些java应用中典型的性能问题和调优tip，主要讲解了以下几类问题的原因分析和排查解决思路：

         一.系统态cpu资源消耗过高

         cpu消耗中有两项主要的消耗是用户态和系统态资源消耗。系统态cpu消耗是指内核对系统资源进行调度时消耗的cpu资源，而用户态则是应用程序进程消耗的cpu资源，比如我们的java应用代码运行的cpu消耗就是用户态消耗。当系统态资源消耗高时，用户态能够能够使用的cpu资源自然就变少了。所以当系统态资源消耗过高时，应用就需要考虑进行性能调优了。java应用满负载运行时建议用户态和系统态的比例为65%~70%/30%~35%。

         在linux下使用top命令查看cpu消耗，top命令使用的一些tips：

         第一行给出当前服务器时间，启动时间，当前登录用户，以及系统负载情况。需要注意的是linux的系统负载是以1分钟、5分钟和15分钟内的平均值 来衡量的。

         第二行列出系统进程情况，总共97个进程，1个进程处于运行状态，96个空闲，0个停止，另外有0个僵尸进程。僵尸进程指的是子进程退出后父进程并没有处理子进程的退出信号，导致子进程变为僵尸进程。

         第三行给出当前CPU的工作情况，%us(user)指的是cpu用在用户态程序上的时间；%sy(sys)指的是cpu用在内核态程序上的时间；%ni(nice)指的是用在nice优先级调整过的用户态程序上的时间；%id(idle)指的是cpu空闲时间；%wa(iowait)指的是 cpu等待系统io的时间；%hi指的是cpu处理硬件中断的时间；%si指的是cpu处理软中断的时间；%st(steal)用于有虚拟cpu的情况， 用来指示被虚拟机偷掉的cpu时间。通常idle值可以反映一个系统cpu的闲忙程度。

         第四行和第五行给出真实内存的使用情况，包括内存总量，使用量，空闲量，以及交换分区的总量，使用量和空闲量。此外关于buffers和 cached的区别需要说明一下，buffers指的是块设备的读写缓冲区，cached指的是文件系统本身的页面缓存。它们都是linux操作系统底层 的机制，目的就是为了加速对磁盘的访问。

         第六行往后是进程列表，常见的这几列的意义分别为：PID(进程号)， USER（运行用户），PR（优先级），NI（任务nice值），VIRT（虚拟内存用量），RES（物理内存用量），SHR（共享内存用量），S（进程 状态），%CPU（CPU占用比），%MEM（内存占用比），TIME+（累计CPU占用时间)。

除了这些信息之外，top还提供了很多命令能帮我更好的解读这些信息，例如按”M”键可以按内存用量进行排序;按”P”可以按CPU使用量进行排 序，这样一来对于分析系统瓶颈很有帮助；

         Top命令使用的几个小技巧：在top视图上按1，会按核来显示；按大写P，按cpu使用率排序；按大写M，按照内存使用率排序；按shift+h，按照线程查看cpu的消耗状况

         《java performance》一书中介绍了一个由于io操作频繁导致的用户态消耗低而系统态资源消耗相对过高的例子，他提供的解决办法是把原先直接使用FileOutPutStream进行文件写操作的程序改成了使用BufferedOutputStream进行操作，从而降低了系统态资源的消耗。这个例子会导致cpu系统态资源消耗高的原因是：io操作频繁会导致iowait较高，iowait高了之后多线程情况下上下文切换（上下文切换的概念：每个cpu同一时间只能执行一个线程，linux采用的是抢占式调度。当一个线程的时间片用完后要切换执行的线程，这时要存储目前线程的状态，并恢复要执行线程的状态。当发生线程切换时cpu存储和恢复线程状态的行为即上下文切换。上下文切换消耗的是cpu的系统态资源
）也随之变高，从而导致cpu系统态消耗高。其实这类问题根本的解决思路是找到消耗系统态资源较高的问题的原因，尽可能减少导致这个问题发生的cpu操作的发生频率。

         二.锁竞争激烈

         在早期的jvm版本，java的锁操作基本上是直接通过执行操作系统层的锁行为来进行，如互斥原语。因此，存在锁竞争问题的java应用就很容易遭受到很高的系统态cpu使用问题。但是在新的jvm版本中，锁的实现有很大部分是通过代码层面来实现，而不直接通过系统原语，这使得存在锁竞争的应用可以不消耗大量的cpu资源。因此，在现代的jvm中，如果应用存在锁竞争，首先消耗的是用户态的cpu资源，而只有在应用存在非常严重的锁竞争时，jvm才会把锁的实现转换成互斥原语，才会消耗系统态cpu资源。在现代的jvm中，排查锁竞争的问题，要做的是找到被竞争的资源和对应造成竞争的源代码，以及找到合适的解决锁竞争的途径。

         性能分析器能够搜集到java 监视器和锁的统计，在此基础上，我们就可以通过性能分析器来呈现应用中代码直到方法层级上的锁竞争情况。大概的使用是在分析器上选择监控锁竞争情况，包括inclusive和exclusive的，exclusive的不仅包括本方法的，还包括方法中调用的其他方法的锁竞争情况。

         书中用一个例子展示了锁竞争的场景。

         先往一个用Collections.synchronizedMap()创建出来的HashMap中放入200W数据量的数据结构对象，对象的id做为key，对象作为value。使用Runtime.availableProcessors()获得核数，根据核数创建指定数量的线程放入java.util.concurrent.ExecutorService生成的线程池中执行。每个线程都会并发得对对HashMap中的数据进行修改修改、删除、新增等操作。而这个HashMap由于时通过Collections.synchronizedMap()api创建出来的，所以所有线程对它的操作都是同步的。

         这个程序在64核的机器上执行时，每S种能够完成615000次操作。但是由于锁竞争，只有8％的cpu使用率。并且使用mpstat能够查看到大量的线程上下文切换。在第二章中提到，大量的线程上下文切换可能是存在锁竞争的一种暗示。暂停一个线程和唤醒一个线程都同样得会导致系统的上下文切换，所以存在锁竞争的程序会存在大量的上下文切换。

         通过性能分析器可以看到，系统消耗了59%的时间在HashMap.get()方法上，这是由于在HashMap上使用了同步的操作导致。

         对于这个问题的解决，书中推荐的是使用ConcurrentHashMap来存放数据。ConcurentHashMap是jdk在HashMap上的改进版本，它和HashMap的本质区别在于在处理同步时，它减少了同步的锁范围，对HashMap进行同步锁，只能使用一个锁，这个锁是作用在整个map数据结构上的，而ConcurrentHashMap使用了32个锁，它是作用在HashMap内部的每个bucket上的，和HashMap的锁机制相比，ConcurrentHashMap的锁减少了锁定的范围。它使得一个线程在操作的时候另一个线程还可以继续操作数据结构中其他bucket的数据。

         所以，对于锁竞争激烈的问题解决办法，推荐的操作是减少锁竞争范围，以及使用jdk中更高效的支持并发的数据结构或者api。

         三.基于数组的数据结构的大小重分配

         在java中有很多数据结构的底层实现都是依赖于数组的，比如String底层依赖char数组，ArrayList和HashMap等容器底层也是类似。当这些数据结构中的数据不停得增长，到一定程度时，就需要对底层的数组进行重分配，重新申请一个新的数组，并把原数组的数据拷贝到新数组中去。这会带来一些问题：数组分配带来的cpu指令、内存消耗、老数组带来的垃圾内存、以及垃圾内存带来的垃圾回收时的cpu资源消耗、底层数组变化导致的cpu cache miss、重分配数组导致得数据结构锁定等。

         第一种情况主要讲StringBuffer和StringBuilder等以char数组为底层的数据结构和类似的以数组为底层的容器的重分配大小对性能带来的影响。当上述的两种数据结构包含的字符数足够大时，这些对象通常都会进行重置大小，通常是把底层持有数据的数组扩大两倍。还是书中先前的例子，在频繁得使用了StringBuilder作为数据结构后。应用的内存dump显示char数组占用的数据占到了大量的内存消耗。这类问题的解决办法可以是不采用StringBuilder的默认构造函数，因为默认使用的是一个16位大小的char数组，一般情况都会不够用，所以可以设置一个更大的值，减少char数组频繁变更导致得重新分配大小。

         另外一种情况是容器大小重分配。在java中，那些底层使用数组来存储的容器类，比如ArrayList，Vector，HashMap，ConcurrentHashMap等，都会因为数组长度的重分配导致性能问题。

问题产生的主要原因是：1，多余的数组重分配和拷贝消耗cpu时间；2，垃圾内存导致的gc；3，重分配也会导致数组中对象的可访问时间变短，cpu缓存不命中。对于HashMap，它的重分配因素包括HashMap的后台数组总长度，当前已put到容器中的kv对数，以及HashMap的loadFoctor，默认的loadFoator是0.75；当kv对数到达总长度×loadFactor时，HasMap会进行resizing，把后台数组的长度增加到两倍。增大loadFactor会导致HashMap的存取速度降低，减小HashMap会导致存取速度增大，但是resizing的几率增大，同样导致性能问题。所以最合适的HashMap使用时估计容器可能存放数量的总数，并设定HashMap的初始产生长度×loadFactor的值大于这个总长度。

         四.局部变量全局化导致的并发下效率降低问题（使用了Random.nextInt使用AtomicLong的CAS方法来获取随机数导致热方法的例子）

         文中使用了Random类的对象做为全局对象导致热方法的例子。在多线程环境下，每个线程都使用同一个Random类的对象来调用nextInt方法来获取随机数，由于Random.next中使用了AtomicLong的CAS方法来获取随机数，在Random对象为全局的情况下，多线程共享Random对象时，由于没有线程同步，会频繁导致CAS失败，进而Random对象需要频繁得进行CAS操作才能正确获得随机数，Random.next的代码如下：

     

         可以看到，当AtomicLong的compareAndSet方法在多线程情况下失败频率增大时，会出现频繁多余得对compareAndSet方法的调用。

         这里介绍一下CAS：CAS的原理是在读取数据时获得一份数据的拷贝，当需要修改数据时比较拷贝和源地址的数据是否一致，即检查数据有没有被修改过，判断数据没有被修改过才进行修改。保证数据的一致性。这个原理和乐观锁相近。乐观锁是在修改数据库记录时读取版本号，每次修改记录会修改版本号，但是修改时会检查当前获得的版本号是否和数据库中的锁一致，如果一致再进行修改。

         上面的这个问题是通过把Random类的对象修改做为线程变量来解决的。这就避免了多个线程同时进行CAS操作以及由此带来的CAS失败。

         我认为，这类问题的本质是对于一些工具类型的api，如果可能在多线程下使用，要考虑多线程使用下的同步问题，如果确实存在并发可能带来的问题，可以考虑以空间换取时间的策略，把全局变量变成局部变量，或者线程变量（java通过ThreadLocalapi可以支持）。