Shulou(Shulou.com)06/01 Report--

This article mainly explains the "JAVA exception has an impact on performance", the content of the explanation is simple and clear, easy to learn and understand, now please follow the editor's ideas slowly in depth, together to study and learn "JAVA exception has an impact on performance" bar!

Experiment

My experiment is based on a simple piece of code that randomly throws an exception. From a scientific point of view, this is not a completely accurate measurement, and I don't know what the HotSpot compiler does with running code. But in any case, this code should give us some basic information.

The results are interesting: the cost of throwing and catching exceptions seems extremely low. In my case, it's about 0.02 milliseconds per exception. Unless you really throw too many exceptions (we mean 100,000 or more), this is basically negligible. Although these results show that exception handling itself does not affect code performance, it does not solve the following question: who is responsible for the huge impact of exceptions on performance?

I obviously missed something important.

On second thought, I realized that I had missed an important part of exception handling. I didn't think about what you did when the anomaly happened. In most cases, you are likely to do more than just catch exceptions! Here's the problem: in general, you try to supplement the problem and make the application still functional with the end user. So what I'm missing is: "supplementary code executed to handle exceptions." Depending on the supplementary code, the performance loss may become quite significant. In some cases this may mean retrying to connect to the server, in others it may mean using the default rollback scenario, which provides a solution that is sure to lead to very poor performance. This seems to give a good explanation for the behavior we see in many cases.

However, I don't think everything is all right here, but I feel that there is something else missing here.

Stack trace

I was still curious about this and monitored any changes in the performance of the situation when collecting strack trace.

What often happens is something like this: write down the exception and its stack trace and try to figure out what the problem is.

To do this, I modified the code to collect extra strack trace for exceptions. This has changed the situation significantly. The performance impact of collecting exception strack trace is 10 times higher than simply catching and throwing an exception. So while strack trace helps to understand what went wrong (and possibly why), there is a performance penalty. Since we are not talking about a strack trace, the impact here is often very large. In most cases, we throw and catch exceptions at multiple levels. Let's look at a simple example: a Web service client connects to the server. First, there is a connection failure exception at the Java library level. After that, there will be client failure exceptions at the framework level, and then there may be business logic call failure exceptions at the application level. So far, a total of three strack trace have to be collected. In most cases, you can see these strack trace in log files or application output, and writing to these longer strack trace often also has a performance impact.

Thank you for your reading. the above is the content of "whether JAVA exceptions affect performance". After the study of this article, I believe you have a deeper understanding of whether JAVA exceptions have an impact on performance, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.