it_worker365

   ::  ::  ::  ::  :: 管理

1. ClassNotFoundException/NoClassDefFoundError/NoSuchMethodException

       参考关于类加载的博文即可,主要关注类加载的方式,类的版本等信息

       https://www.cnblogs.com/baihuitestsoftware/articles/6382733.html

       https://www.cnblogs.com/it-worker365/p/11269635.html

2.Cpu us消耗高

linux下获取占用CPU资源最多的10个进程,可以使用如下命令组合: 或者top进入后大写的M

//加标题去标题,第三列倒序排序
ps -aux | head -1 ; ps aux | grep -v PID | sort -rn -k +3 | head
//排序
ps -aux | sort -nr -k3 | head -10

       是否是gc过于频繁,打开gc日志-Xloggc:./gc.log或者通过jstat -gcutil来查看gc和内存的情况,这种根据内存问题来处理

       下面根据top -H -p/ jstack等命令查看是否有死锁,很深的循环或递归,也可能是序列化反序列化之类对象突然变大,计算突然增加   

/**
 * Created by itworker365 on 5/17/2017.
 */
public class CpuBusyTest implements Runnable{
    public static void main (String[] args) {
        for (int a = 0; a < 1000; a++) {
            CpuBusyTest test = new CpuBusyTest();
            Thread t = new Thread(test, "t-" + a);
            t.start();
        }
    }

    @Override
    public void run() {
        long start = System.currentTimeMillis();
        long k = 0;
        for (long i = 0; i < 2000000000; i++) {
            k = 1 + i;
        }
        System.out.println(Thread.currentThread().getName() + "-----" + (System.currentTimeMillis() - start));
    }

默认TOP按照进程显示,直接输入TOP看到占用最多的进程,如下,%CPU 99.8

top -H -p ID查看该进程下的线程情况,如果有一个特别高,可以找到PID,然后转换为16进制,比如2687-》0xA7F,打印进程堆栈 jstack ID在其中找到0xA7F

我的例子并没有对应,因为中间停掉了,所以意思明白就好,这里打印出jstack信息,找到对应的线程,查看他的状态。

 

一个出现死锁的例子

/**
 * Created by itworker365 on 5/4/2017.
 */
public class LockTest {
    private static String A = "A";
    private static String B = "B";
    public static void main (String[] args) {
        new LockTest().deadlock();
    }
    private void deadlock () {
        Thread t1 = new Thread(new Runnable() {
            @Override
            public void run() {
                synchronized (A) {
                    try {
                        Thread.sleep(2000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    synchronized (B) {
                        System.out.println("AB");
                    }
                }
            }
        });
        Thread t2 = new Thread(new Runnable() {
            @Override
            public void run() {
                synchronized (B) {
                    synchronized (A) {
                        System.out.println("BA");
                    }
                }
            }
        });
        t1.start();
        t2.start();
    }
}

jstack之后显示deadlock信息

 3. 内存问题

linux下获取占用内存资源最多的10个进程,可以使用如下命令组合:或者top进入后大写的P

ps -aux | head -1 ; ps aux | grep -v PID | sort -rn -k +4 | head
ps -aux | sort -nr -k4 | head -10

    java.lang.OutOfMemoryError: Unable to create new native thread

    用命令统计出当前总java线程数ps -eLf | grep java -c, 查出当前允许的最大句柄数ulimit -u,对比看是否正确,根据需要做出对应的调整,btrace找到哪里创建的线程@OnMethod(clazz="java.lang.Thread", method="start")

    Executors.newCachedThreadPool这种来创建了一个没限制大小的线程池

    java.lang.OutOfMemoryError: Heap Size或GC overhead limit exceeded

    启动时加入-XX:+HeapDumpOnOutOfMemoryError在溢出时dump内存,之后再通过mat等工具再分析,通过btrace来定位代码

    PermGen Space 跟踪class装载情况,用traceClassLoading或者btrace,@OnMethod(clazz="java.lang.ClassLoader", method="defineClass")

    native OOM:Direct ByteBuffer(NIO)-XX:MaxDirectMemorySize=500m来实现当Direct ByteBuffer使用到500m后主动触发fgc来回收

    到底什么算频繁,如果每隔10s或更短时间就来一次cms gc或full gc才算得上

    jmap -dump:format=b,file=***log         jhat ***.log或其他工具分析

    jmap -histo打印加载的对象    jmap -histo:live来触发fgc

java.lang.OutOfMemoryError: Java heap space堆溢出,大对象多次没被回收,对比回收前后的内存使用量

StackOverflowError:递归,循环,局部变量过长,参数过多,局部变量作用域外没有释放等

java.lang.OutOfMemoryError: unable to create new native thread  操作系统没有足够的资源来创建线程,解决方法就是减少线程数量或者-Xss减小单个线程的大小

java.lang.OutOfMemoryError: PermGen space 类太多,是多个classloader或者太多反射动态加载类导致

4.文件占用大小排序

du -s -h /* | sort -nr

5. Java进程crash或退出

默认情况下jdk会生成hs_err[pid].log的文件,core dump打开的话也会生成core dump文件

-XX:+PrintGCDetails

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/log/gcdump

遇到问题分而治之,隔离问题。将问题隔离到尽可能小的领域中,比如某个特定系统、特定版本、 甚至特定机器中。之后如果是java的问题,还可以继续分析是java应用、容器、或者jdk的问题,最后应该能确定到某个模块的某些代码、一次 commit、一行配置的问题。整个排查问题的过程就是一个从上到下,一步步缩小问题范围的过程。

状态数据大致可以分为两类:

一是监控类数据,收集这类数据对于应用的性能影响很小,基本可以忽略不计,所以可以持续收集,比如GC log,应用log等;

第二类是某些瞬时数据,这些数据要么收集的代价很大,很影响系统性能,要么时效性很高,过了故障点一切可能就都不一样了,所以不能 持续收集,必须迅速的在故障出现点自动采集,比如Heap dump,core dump等。

 

posted on 2017-05-17 15:58  it_worker365  阅读(366)  评论(0编辑  收藏  举报