平时项目中有时遇到cpu过高的情况，在此基于自己有限的经验写个分享，此处的服务器都是基于linux平台。
cpu的占有线程类型总的来说分为两种：
us ：用户空间占用CPU百分比
sy ：内核空间占用CPU百分比
在linux下可以通过top命令查看详细，示例如下：
一般来讲CPU us高的解决方法：
CPU us 高的原因主要是执行线程不需要任何挂起动作，且一直执行，导致CPU 没有机会去调度执行其他的线程。
CPU sy高的解决方法：
CPU sy 高的原因主要是线程的运行状态要经常切换，对于这种情况，常见的一种优化方法是减少线程数。
我平时具体的步骤如下：
1.得到线程最高的几个id
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=0x1a5 runnable 0x35f：memcache线程"memcache5-CacheThread" prio=1 tid=0x0000002b3d277de0 nid=0x35f runnable [0x0000000042755000..0x0000000042755c30]0x35e：memcache线程"memcache1-CacheThread" prio=1 tid=0x0000002b371212f0 nid=0x35e runnable [0x0000000042654000..0x0000000042654cb0]0x14e9：RMI线程"RMI TCP Connection(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高，接下来就需要优化了，可以从业务和技术手段两方面来进行，平时工作中比较常用的技术手段：
弹性时间：对高使用率的请求，分散到不同的时间，比如采用队列或异步，减少同一时间处理的请求。
批处理或定时任务：把请求组合成批，这样可以使得时间真真的都有效的用在了处理上，而不是网络传输等准备工作上。
缓存：将结果缓存起来，空间换时间。
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程序时，通常多个小的对象比大的对象分配起来更加高效。