「java线上分析定位」java定位功能
本篇文章给大家谈谈java线上分析定位，以及java定位功能对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
java中如何自动定位
自动定位需要特定的api，比如百度等。
在需要的地方调用第三方提供的api调用定位相关代码就好。
Java问题定位之如何借助线程堆栈进行问题分析
我们可以从三个方面分析：堆栈的局部信息，一次堆栈的统计信息，多个堆栈的对比信息。
从一次的堆栈信息中，我们可以直接获取以下信息：
每一个线程的调用关系，当前线程在调用哪些函数
每个线程的当前状态，持有哪些锁，在等待哪些锁？
从一次堆栈信息中，我们还可以统计以下信息：
是否有很多线程都在等待同一个锁，说明这个系统存在性能瓶颈，导致了锁竞争
当前线程的总数量
大多数线程在干什么，在执行什么代码？
从多次的堆栈信息中，可以得到以下信息：
一个线程是否长期执行，如果每次打印堆栈某个线程一直处于同样的调用上下文中，那么说明这个线程一直执行这段代码，此时要根据代码逻辑检查，是否合理。
某个线程是否长期存在获取不到锁的情况，线程是否永远得不到唤醒，如果某一个线程一直等在一个锁，就要检查占用这个锁的线程为什么不释放。
如果说打印一次线程堆栈是平面，那么打印多次就是立体了，我们可以看到一段运行的情况。
接下来从以下几个方面分析：
线程死锁分析
java代码导致的cpu过高分析
死循环分析
资源不足分析性能瓶颈分析
线程死锁分析
线程死锁的原因：当两个或者多个线程正在等待被对方占用的锁，死锁就会发生。在时间0的时候，线程0占用lock0锁，线程1占用lock1锁。在时间1，进行了其它操作，在时间2，线程0，1企图持有对方的锁，但是由于2个锁已经在时间0被锁住，所以只能等待释放。由于这两个线程互相要等待被对方占有的锁，自己才能继续，因此就造成了死锁。
我们看以下示例：
从打印的堆栈信息可以看到第一行，found one java-level deadlock ，如果线程存在死锁情况，堆栈会直接给出死锁的分析结果。从堆栈信息中可以看到，TestThread2中持有锁0x22bffb10但在等待锁0x22bffb08，相反，TestThread2中持有锁0x22bffb08，但在等待锁0x22bffb10。这里说的死锁是真正意义上的死锁，由于代码的错误导致的，严重程度取决于线程执行什么性质的功能代码，如果是关键功能，可能造成整个系统的瘫痪。死锁的2个或者多个线程是不消耗cpu的，所以认为死锁会导致cpu100%是错误的。
Java代码死循环等导致的cpu过高的分析
当系统负载大的时候会导致cpu过高，但不正确的代码也会导致cpu过高，比如死循环。我们如何从线程堆栈中找到死循环的线程呢？方法就是多次打印堆栈信息，通过对比前后的线程，找到一致运行的线程。具体步骤如下：
通过上一篇文章介绍过的方法打印第一次堆栈信息
等待一定时间，再次打印第二次堆栈信息
预处理2次堆栈信息，首先排除等待状态的线程，这种状态的线程不消耗cpu，前面已经讲过。我们只关注runnable状态的线程。
比较前后2次预处理后的线程，找出一段时间一直活跃的线程，如果2次堆栈信息在同一个线程处于同样的调用上下文，就列为重点怀疑对象。接下来结合代码逻辑检查该线程执行的上下文所对应的代码是不是属于应该长期运行的代码。
如果通过堆栈定位没有发现可疑代码，那么cpu高可能是不恰当的内存设置导致的频繁gc，从而导致的cpu过高。
资源不足等导致的性能下降分析
这里说的资源包括数据库连接。大多数时候资源不足和性能瓶颈是同一类问题。当资源不足，就会导致资源的竞争，请求该资源的线程会被阻塞或者挂起，自然就导致性能下降。系统对于资源，一般的设计模式是：当需要资源的时候，获取资源，当不需要的时候就把资源释放掉。如果暂时没有可用的资源，就等待在哪里。如果有别的线程释放资源，那么等待的线程被notify，等待的线程获得资源继续运行。一般的资源设计都遵循wait/notify模式。如果资源不足，那么有大量的线程等待资源，打印的线程堆栈如果具有这个特征，说明该资源存在瓶颈。
大量的线程停在同样的调用上下文上。
资源数量配置太小，如数据库连接数，如果系统压力过大，资源不足导致线程不能及时获得资源而等待在那里。
获得资源的线程把持资源时间太久，导致资源不足。比如把一段和操作数据库无关的代码放在获取数据库连接和释放数据库连接之间。
设计不合理导致的资源占用太久，比如sql没有加索引导致执行sql太慢。
资源用完后，没有关闭导致资源泄漏或者减少。
资源不足往往表现出一个现象是系统越来越慢，并最终停止响应，超时。
多个锁导致的锁链分析
很多线程在等待不同的锁，有的锁竞争可能是由于另一锁对象竞争导致，这时候需要找到根源。
看到有40多个线程在等待锁0xbef17078，首先找到已经占有这把锁的线程thread-196
看到thread-196占有锁，0xbef17078,但又在等待锁0xbc7b4110，那么此时需要再找占有0xbc7b4110这个锁的线程，即thread-609。
那么占有锁0xbc7b4110的线程是问题的根源，下一步就是查到底为什么这个线程长时间占有这个锁。可能的原因是持有这把锁的线程正在执行的代码性能比较低，导致占有时间过长。
java的定位
java是目前主流的面向对象程序设计语言，没有之一，java无疑是目前应用最广泛的面向对象程序设计语言，C++由于不是纯的面向对象设计语言，而且有较多不便的编程限制，应用受到局限，java几乎能满足所有bs、cs的开发需要，目前仍然有着旺盛的生命力
请教java堆外内存泄漏分析定位方法
4.Java中参数都是传值的。
对于基本类型，大家基本上没有异议，但是对于引用类型我们也不能有异议。
Java内存泄露情况
JVM回收算法 是很复杂的，我也不知道他们怎么实现的，但是我只知道他们要实现的就是：对于没有被引用的对象是可以回收的。所以你要造成内存泄露就要做到：
持有对无用对象的引用!
不要以为这个很轻易做到，既然无用，你怎么还会持有它的引用? 既然你还持有它，它怎么会是无用的呢?
以下以堆栈更经典这个经典的例子来剖析。
Java代码
public class Stack {
private Object[] elements=new Object[10];
private int size = 0;
public void push(Object e){
ensureCapacity();
elements[size++] = e;
}
public Object pop(){
if( size == 0)
throw new EmptyStackException();
return elements[--size];
}
private void ensureCapacity(){
if(elements.length == size){
Object[] oldElements = elements;
elements = new Object[2 * elements.length+1];
System.arraycopy(oldElements,0, elements, 0, size);
}
}
}
上面的原理应该很简单，假如堆栈加了10个元素，然后全部弹出来，虽然堆栈是空的，没有我们要的东西，但是这是个对象是无法回收的，这个才符合了内存泄露的两个条件：无用，无法回收。
但是就是存在这样的东西也不一定会导致什么样的后果，假如这个堆栈用的比较少，也就浪费了几个K内存而已，反正我们的内存都上G了，哪里会有什么影响，再说这个东西很快就会被回收的，有什么关系。下面看两个例子。
例子1
Java代码
public class Bad{
public static Stack s=Stack();
static{
s.push(new Object());
s.pop(); //这里有一个对象发生内存泄露
s.push(new Object()); //上面的对象可以被回收了，等于是自愈了
}
}
因为是static，就一直存在到程序退出，但是我们也可以看到它有自愈功能 ，就是说假如你的Stack最多有100个对象，那么最多也就只有100个对象无法被回收其实这个应该很轻易理解，Stack内部持有100个引用，最坏的情况就是他们都是无用的，因为我们一旦放新的进取，以前的引用自然消失！
例子2
Java代码
public class NotTooBad{
public void doSomething(){
Stack s=new Stack();
s.push(new Object());
//other code
s.pop();//这里同样导致对象无法回收,内存泄露.
}//退出方法,s自动无效,s可以被回收,Stack内部的引用自然没了,所以
//这里也可以自愈,而且可以说这个方法不存在内存泄露问题,不过是晚一点
//交给GC而已,因为它是封闭的,对外不开放,可以说上面的代码99.9999%的
//情况是不会造成任何影响的,当然你写这样的代码不会有什么坏的影响,但是
//绝对可以说是垃圾代码!没有矛盾吧,我在里面加一个空的for循环也不会有
//什么太大的影响吧,你会这么做吗?
}
关于java线上分析定位和java定位功能的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
发布于：2022-11-25，除非注明，否则均为原创文章，转载请注明出处。