Why does e.printStackTrace () in java cause locking?

This article mainly introduces why e.printStackTrace () in java leads to locking. It is very detailed and has a certain reference value. Friends who are interested must read it!

Will e.printStackTrace () cause locking?

It's just printing. How is that possible?!

Don't exclaim the impossible yet, just listen to me in detail.

First, take a look at screenshot 1:

Pay attention to the lower right corner, the red box. What is this piece of memory? Non-heap! So, on the left is the code cache memory, and the red box on the right is the memory area for string pools, constants, and basic type data. And? It's full.

What's the reason?

E.printStackTrace ()!

What about the consequences of being full? The entire web service, after access, does not respond, it is regarded as stuck.

Let's take a look at screenshot 2:

See how many web request threads are stuck in the print step! Why? To print strings to the console, there should be space in the memory block where your string constant pool is located. However, because the string generated by the e.printStackTrace () statement records stack information, it is too long and too much, and the memory is filled up!

Note the above code statement: 4208 lines!

Look at figure 3:

It's all right, it's all right, it's all right to blame someone. This is the trouble caused by this code! Of course, I admit that the code that is hosted by try is inherently problematic, causing many calls to throw exceptions.

So, let's sort out the whole story again:

There are a large number of requests to access this interface within a short period of time-> there is a problem with the code itself. In many cases, an exception is thrown-> e.printStackTrace () to print the exception to the console-> generate an error stack string to the string pool memory space-> this memory space is suddenly occupied-> the thread that starts to produce strings in this memory space has not been fully produced yet. There is no space-> a large number of threads produce strings in the middle, wait here (wait for memory to continue to do)-> wait for each other, wait for memory, lock, the whole application is dead.

To sum up, this is the murder caused by e.printStackTrace ().

Summing up is of course important. There are three points:

1. Code quality, dear, can't we continue to wave happily without throwing an exception?

2, do not use e.printStackTrace () ah, this thing, after the release of the project, in addition to constantly swiping the console, there is no use ah, you are using log objects to output to the log file.

3, push out, in java, will generate a large number of string method, you must be careful when using, do not accidentally hold up to the stomach (string pool belongs to so little non-heap memory space), hold up to the stomach, will die ah.

The above is all the contents of the article "Why does e.printStackTrace () cause locking in java?" Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!