Three common Java application performance challenges

Java is a great language. It manages memory and teaches Object-Oriented Programming (IDEAS) so that we can better use it for coding. In addition, it is indeed a language for "writing once and running everywhere. However, Java applications may encounter some common performance challenges that developers and applications are familiar.

Memory leakage

One of the biggest advantages of Java is its ability to manage memory models. Java cleans up objects when they are no longer used. Older languages require manual memory management, but developers prefer to spend time focusing on core language logic rather than worrying about memory allocation.

Even so, there is no guarantee that there is no problem with Java memory management. It provides a memory management model, or creates/destroys unused objects (these objects) all are stored in Java's "heap". Memory leakage is usually the result of incorrect programming. Generally, developers do not eliminate all references to an object. Therefore, the heap (Space) gradually exhausted, ApplicationProgramWill also crash.

Most people use the heap dump and/or profiler to diagnose memory leaks. Heap dump allows you to see which object holds a reference to the set. It tells you where the set is, but does not tell you who is accessing the set or other features that allow you to explore the root cause. The heap dump usually occupies a large amount of space. In the Gigabit bytes, analyzing and opening a heap dump requires a lot of resources, then reading it, and finding out the problem.

The second approach is to combine the heap dump and the event probe so that you can approach the nature of the problem, but not much. The memory analyzer tries its best to help you analyze your heap dump. They have real-time data and now know who created the object, but still do not know the real root cause of the leakage.

Both heap dump and analyzer are useful for development and pre-production. However, analyzer is also unavailable once the application gets out of control. One of the most effective ways to isolate and solve memory leaks is through transactions (transactions) andCodePath Analysis. By taking a transaction snapshot, you can obtain the cause and cause of the problem, which usually leads to less downtime and better MTTR.

Slow SQL

Almost every application uses a JDBC database. A common problem in applications is poor SQL Performance, which is sometimes caused by the absence of an index on a field, the amount of data obtained, or other reasons. This is not conducive to application performance, because most applications involve a lot of SQL calls in each application request.

There may be many causes of slow SQL Execution, but one of them is particularly prominent: object-relational ing (ORM ).

Orm becomes the basic technology of today's two business applications (Object-Oriented applications (Java ,. net) and relational databases (Oracle, MySQL, PostgreSQL, and so on) integrated with the preferred method. Today, most applications use relational databases. For many developers, the (ORM) technology can eliminate the complexity that needs to be escalated to explore how the two technologies interact. However, Orm puts the application at an extra burden and greatly affects the performance of the application, while everything looks good on the surface.

In most cases, the time and resource occupation consumed by data retrieval are far greater than the time and resources required for data processing. Therefore, it is not surprising that performance considerations often include tools and methods for accessing and storing data.

Although developers use it intuitively (hide complexity), ORM should take a large proportion in terms of application performance to ensure that (developers) understand the essence of the problem.

Thread/synchronization

The problems caused by synchronization are often difficult to identify, but their impact on performance is very significant.

The most fundamental need for synchronization lies in Java's support for concurrency, which is achieved by executing different thread code in the same process. Individual threads can share the same resources and objects in the memory. Although it is an effective way to do more work (when the thread is waiting for the completion of the I/O operation, another thread can use the CPU for computing ), however, application interference and consistency problems are also exposed.

To prevent this, the programmer introduces the "synchronized" keyword in the program to force the execution sequence of concurrent threads. "Synchronized" is used to prevent threads from obtaining the same resource at the same time and prevent data inconsistency.

However, in practice, this simple mechanism brings great side effects. Modern Enterprise applications often adopt multi-threaded implementation mode. When multiple threads are executed at the same time, competition for "shared" objects is intensified. Synchronization will effectively force concurrent processing to switch to sequential execution.

Currently, there is no silver bullet for thread and synchronization issues ). Some developers rely on defensive programming methods, such as locking, while others rely on STM (software transactional memory systems) to alleviate this problem. The best development organization is the teams that balance the burden of code review/rewriting and performance issues.

These are only application performance problems that Java developers must face every day. Many useful performance tasks can greatly reduce these problems.

This article is transferred from www.35java.com