This article is from Recently Zhu Zhu, created from Recently Zhu Zhu. Please indicate the source for reprinting.
This solution is used in enterprises, suitable for Java primary development learning, reference.
The number of words and lines in this article, patient reading will be rewarding
This is the 21st day I have insisted on updating the text in the Nuggets. The time spent in this part is huge. It can be seen that if you want to write well, you need not only the writing skills but also the corresponding foundation, and a little bit of expressive ability. come on.
1. Description
We often encounter OOM and deadlock waiting when we are tuning the JVM, so if we find these two types of situations, we must detect them, detect which part has a problem, and use some tools to locate the problem And solve it, and adjust it reasonably.
Of course, JVM tuning is not achieved overnight. The JVM needs to be tuned multiple times to optimize it, and there is no optimal solution, because you may find that this time the tuning is already very good, but it may be more difficult to modify the parameters. It was better last time.
The frequently encountered error OOM (out of memory) is actually memory overflow (heap memory overflow). After the heap memory overflows, the problem can be found by locating, analyzing the problem, and solving the problem. There are many ways to solve the problem, such as increasing memory, bug repair, etc.
Deadlock is also a major factor affecting the response time of the project. If the deployed program suddenly does not respond, you can check whether the program has a deadlock.
2. Memory overflow
Heap memory overflows OOM, set the heap memory smaller, dump the file when the memory overflows, and record the heap memory situation at the moment of memory overflow for easy analysis
2.1 Example operation:
Try creating and adding 10 million strings to an ArrayList, each string being the concatenation of 1000 randomly generated UUIDs. OutOfMemoryError is caused because the program uses a lot of memory . Each time the inner loop runs, a new String object is created to hold the concatenation of the 1000 UUIDs. Since Java Strings are immutable, each connection creates a new String object, which causes a lot of memory usage. The ArrayList also holds references to all of these String objects, further increasing memory usage.
First simulate the OOM and then analyze and explain it.
code:
代码保存的路径不要使用中文路径。会找不到
配置VM options:
输出dump文件 配置：
-Xms8m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError，当内存溢出输出hprof文件（dump文件）
运行代码：
发生内存溢出，获取到Dump文件
2.2实际定位分析：
使用Mat软件检测，Mat在我前面JVM说明中有说明。Mat下载存放的路径也不能存在中文
将内存溢出所获取到的Dump文件放入MAT，MAT自动分析。
可以看到，有86.31%的内存由Object[]数组占有，所以比较可疑。
分析：已经有超过80%的内存都被它占有，这是非常有可能出现内存溢出的。 查看详情：点击Detail
可以看到集合中存储了大量的uuid字符串。说明内存溢出部分就在这个字符串存储的部分。
这样就能简单定位到内存溢出的部分了。
3.死锁检测
死锁问题一般都是线程的问题。
3.1示例操作：
将java文件传入服务器，并且运行这个java类。
Java 代码创建了两个并发运行的线程，Thread1 和 Thread2。两个线程都尝试以不同的顺序获取两个不同对象 obj1 和 obj2 的锁。
Thread1 获得了 obj1 的锁，然后休眠了 2 秒。在此期间，Thread2 获得了 obj2 上的锁。2 秒过后，Thread1 尝试获取 obj2 上的锁，同时仍持有 obj1 上的锁。如果 Thread2 还持有 obj2 上的锁并等待 obj1 上的锁，这会造成潜在的死锁情况。如何进行检测说明
3.2实际定位分析：
在死锁的定位中我们使用的是Arthas来检测，Arthas在我前面JVM说明中有说明。启动Arthas。使用thread -b来查看正在运行的线程。当然上边的java类也是需要启动的，你需要再次启动一个服务器操作界面进行Arthas的操作
You can know exactly: which line is the deadlock in the code, and it can be seen from the output that the deadlock is at line 23
The article is all for personal understanding. If you find that some parts are different from what you know, please point it out in the comment area and welcome to discuss.