JVM Tuning Summary (11)-Rethinking

The paradox of garbage collection

The so-called "Analyticals defeated Xiao". Java's garbage collection does bring a lot of benefits and facilitates development. However, in some high-performance, high-concurrency scenarios, garbage collection is a bottleneck that restricts Java applications. Currently, the JDK garbage collection algorithm does not always solve the garbage collection pause problem, because this pause seriously affects the corresponding time of the program, causing congestion or accumulation. This is also an important reason for subsequent JDK additions to the G1 algorithm.

Of course, the above is from a technical point of view to solve the problem of garbage collection, but from the system design we need to ask:

do we need to allocate so much memory space to the app?

Can we design our system by using memory effectively rather than by expanding memory?

What we put in our memory.

What do I need to put in memory? Personally, what you need to put in memory is what your app needs to be used again in the near future . Think about it, if you don't use these things in the future, why put in memory? Is it better to put files and databases? These things generally include:

1. System runtime business-related data. such as the session in the Web application, the session of the instant message, and so on. These data are typically required during a user access cycle or during a usage process.

2. Cache. The cache is much more, and all you have to do is get a quick access to the area. In fact, the above business data can also be understood as a cache.

3. Threads.

So, can we assume that if we don't put business data and caches in the JVM, or separate them, then the memory required for Java applications to be used will be greatly reduced and garbage collection time will be reduced accordingly.

I think it's possible.

The way to solve

Database, File system

It's the simplest way to put all the data into a database or file system. In this way, the memory of the Java application is basically equal to the memory required to process a peak concurrent request. Data acquisition is obtained from the database and the file system on each request. It can also be understood that after a business visit, all objects can be recycled.

This is the most efficient way to use memory, but from an application point of view, this approach is inefficient.

Memory-hard disk mapping

The problem above is because we use the file system to bring inefficiency. But if we do not read and write the hard disk, but writing memory, efficiency will improve a lot.

Both the database and the file system are really persistent, but when we don't need to be so persistent, we can do some work--putting the memory on the hard drive.

Memory-hard disk mapping is good and powerful, and it has no effect on both caching and memory usage in Java applications. Java applications or Java applications, he only knows whether to read or write files, but in fact, memory.

This approach combines both Java application and caching benefits. The widespread use of memcached is also representative of this category.

Deploy multiple JVMs on the same machine

This is also a good way to be divided into vertical and horizontal demolition. The vertical disassembly can be understood as dividing the Java application into different modules, each of which uses a separate Java process. A cross-sectional application deploys multiple JVMs with the same functionality.

By deploying multiple JVMs, you can control the memory of each JVM in a range that can be tolerated by garbage collection. However, this is equivalent to distributed processing, and the additional complexity required to evaluate it. In addition, there are distributed support for this JVM can be considered, do not want Money OH:)

Object life cycle of program control

This approach is ideal in the way that the current virtual machine is not yet, purely hypothetical. That is, consider programmatically configuring which objects can be skipped directly during garbage collection, reducing the time that garbage collection threads traverse tokens.

This is equivalent to telling the virtual machine some objects at the time of programming that you can collect them after * hours or by code identifiers (like C, C + +), before you even have to traverse him is not effective, he must be still quoted.

This way, if the JVM can be implemented, the individual thinks it will be a leap, Java has the advantage of garbage collection, and C, C + + memory controllability.

Thread Assignment

Java's blocking threading model can be largely discarded, and the current mature NIO framework is much more. The problem with blocking IO is a linear increase in the number of threads, while NiO can be converted into a constant thread. Therefore, NiO is still the only option for service-side applications. However, is the AIO brought to us in the JDK7 to be a bright one? We wait and see.

The other JDK

This article is all about Sun's JDK, and the common JDK is jrocket and IBM's JDK. The jrocket is much higher in IO than Sun's, but the Sun JDK6.0 is also a big improvement later. And Jrocket also has an advantage in garbage collection, which can set the maximum pause time for garbage collection to be attractive. However, after the implementation of the system Sun G1, there will be a qualitative leap in this respect.

JVM Tuning Summary (11)-Rethinking