平时项目中有时遇到cpu过高的情况，在此基于自己有限的经验写个分享，此处的服务器都是基于linux平台。

cpu的占有线程类型总的来说分为两种：

us ：用户空间占用CPU百分比

sy ：内核空间占用CPU百分比

在linux下可以通过top命令查看详细，示例如下：

一般来讲CPU us高的解决方法：

CPU us 高的原因主要是执行线程不需要任何挂起动作，且一直执行，导致CPU 没有机会去调度执行其他的线程。

CPU sy高的解决方法：

CPU sy 高的原因主要是线程的运行状态要经常切换，对于这种情况，常见的一种优化方法是减少线程数。

我平时具体的步骤如下：

1.得到线程最高的几个id(ps- process state)

ps  -eLo pid,lwp,pcpu | grep  15285|sort -nk 3

2.导出JAVA线程栈信息

命令：kill -3 [PID] 或者 jstack

3.从栈信息中找到线程数多的几个

命令：sort  文件名 | uniq -c | sort -nk 1

4.分别分析线程数最多的前十个线程和线程占用cpu最高的前10个线程

这步是最关键的，找出这些异常点，比如某个业务功能点占用较高的cpu或者某种类型的线程数量比较多，这个和业务以及具体程序紧密关联的，在此就不多说了。

5.分析占用cpu最高的前10个线程，结果示例如下：

0x1a5：gc线程

"Concurrent Mark-Sweep GC Thread#0" prio=1 tid=0x0000002b29df1400 nid=0x1a5runnable

0x35f：memcache线程

"memcache5-CacheThread" prio=1 tid=0x0000002b3d277de0 nid=0x35frunnable [0x0000000042755000..0x0000000042755c30]

0x35e：memcache线程

"memcache1-CacheThread" prio=1 tid=0x0000002b371212f0 nid=0x35e runnable [0x0000000042654000..0x0000000042654cb0]

0x14e9：RMI线程

"RMI TCPConnection(102)-10.23.241.59" daemon prio=1 tid=0x0000002b37e72790 nid=0x14e9 runnable [0x000000005103c000..0x000000005103deb0]

0x1be：memcache线程

"memcache5-CacheThread" prio=1 tid=0x0000002b3dba4790 nid=0x1be runnable [0x0000000041a48000..0x0000000041a48eb0]

0x1bd：memcache线程

"memcache1-CacheThread" prio=1 tid=0x0000002b3fb70340 nid=0x1bd runnable [0x0000000041947000..0x0000000041947b30]

0x1af：jdk编译线程

"CompilerThread1" daemon prio=1 tid=0x0000002b30e11620 nid=0x1af waiting on condition [0x0000000000000000..0x000000004123f7c0]

0x1ae：jdk编译线程

"CompilerThread0" daemon prio=1 tid=0x0000002b30e10280 nid=0x1ae waiting on condition [0x0000000000000000..0x000000004113e440]

0x1684：http请求线程，通过该线程栈可以看到此处调用的是hibernate查询

"http-8080-Processor123" daemon prio=1 tid=0x0000002b37dfd9d0 nid=0x1684 runnable [0x000000005afd7000..0x000000005afdcd30]

--------------------------------------------------------------------------------------------------------------------------------

6.系统优化

如果找出了哪些功能点占用cpu高，接下来就需要优化了，可以从业务和技术手段两方面来进行，平时工作中比较常用的技术手段：

弹性时间：对高使用率的请求，分散到不同的时间，比如采用队列或异步，减少同一时间处理的请求。

批处理或定时任务：把请求组合成批，这样可以使得时间真真的都有效的用在了处理上，而不是网络传输等准备工作上。(减少网络传输、数据库连接、socket连接)

缓存：将结果缓存起来，空间换时间。

--------------------------------------------------------------------------------------------------------------------------------

7.如果是gc线程比较费时，则需要进一步的定位：

首先查看一下gc策略是否合理，然后用命令jmap -F -dump:live,file=jmap.hprof [PID] 导出内存dump文件，我一般每隔5s导一次，一共导出3次。用Eclipse Memory Analyzer分析导出来的文件，分析是哪个类占用内存比较多，分析出可能存在内存泄露的地方。

注意jvm分配内存时一个大对象的分配比多个小对象的分配效率要低，如果对象比较大，进行拆分能提高效率，具体原因如下：

Java对象所占用的内存主要从堆上进行分配，堆是所有线程共享的，因此在堆上分配内存时需要进行加锁，这导致了创建对象开销比较大。当堆上空间不足时，会触发GC，如果GC后空间仍然不足，则抛出OutOfMemory错误信息。Sun JDK为了提升内存分配的效率，会为每个新创建的线程在新生代的Eden Space上分配一块独立的空间，这块空间称为TLAB(Thread Local Allocation Buffer)，其大小由JVM根据运行情况计算而得，可通过-XX:TLABWasteTargetPercent来设置TLAB可占用的Eden Space的百分比，默认值为1%。JVM将根据这个比率、线程数量及线程是否频繁分配对象来给每个线程分配合适大小的TLAB空间 。在TLAB上分配内存时不需要加锁，因此JVM在给线程中的对象分配内存时会尽量在TLAB上分配，如果对象过大或TLAB空间已用完，则仍然在堆上进行分配，因此在编写Java程序时，通常多个小的对象比大的对象分配起来更加高效。