The paradox of garbage collection
The so-called "success also Xiao He defeats Xiao He". Java's garbage collection does bring a lot of benefits and convenience to development. However, in some high-performance and high-concurrency situations, garbage collection has indeed become a bottleneck restricting Java applications. At present, the garbage collection algorithm of JDK cannot solve the problem of pause during garbage collection, because this pause seriously affects the corresponding time of the program, causing congestion or accumulation. This is also an important reason for the subsequent addition of the G1 algorithm to the JDK.
Of course, the above is to solve the problems caused by garbage collection from a technical point of view, but from the perspective of system design, we need to ask:
Do we need to allocate such a large memory space to the application?
Can we design our systems by using memory efficiently rather than by expanding it?
what's in our memory
What do I need to put in memory? In my opinion, what needs to be in memory is what your application needs to use again in the near future . Think about it, if you don't use these things in the future, why put them in memory? Isn't it better to put files and databases? These things generally include:
1. Business-related data when the system is running. For example, the session in the web application, the session of the instant message, etc. These data generally need to exist in a user access cycle or a use process.
2. Cache. There are more caches, and everything you want to access quickly can be placed here. In fact, the above business data can also be understood as a kind of cache.
3. Thread.
Therefore, can we think that if we do not put business data and caches in the JVM, or separate them, the memory required by Java applications will be greatly reduced, and the garbage collection time will be reduced accordingly. .
I think it is possible.
solution
database, file system
Putting all the data into a database or file system is the easiest way. In this way, the memory of the Java application is basically equal to the memory required to handle a peak concurrent request. Data is fetched from the database and file system on every 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 it is inefficient from an application point of view.
memory-disk mapping
The above problem is because of the inefficiencies that we have with the file system. But if we are not reading and writing to the hard disk, but writing to the memory, the efficiency will be much improved.
The database and file system are actually persistent, but when we don't need such persistence, we can make some workarounds - use the memory as a hard disk.
The memory-to-disk mapping is very good and powerful, it uses the cache and has no impact on the memory usage of the Java application. A Java application is still a Java application. He only knows that what is read and written is still a file, but it is actually memory.
This method has both the benefits of Java applications and caching. The widespread use of memcached is also representative of this category.
Deploy multiple JVMs on the same machine
This is also a good way, which can be divided into vertical split and horizontal split. Vertical demolition can be understood as dividing a Java application into different modules, each module using an independent Java process. The horizontal split is the deployment of multiple JVMs for applications with the same function.
By deploying multiple JVMs, the memory of each JVM can be controlled within a range that can be tolerated by garbage collection. But this is equivalent to distributed processing, and the additional complexity it brings needs to be evaluated. In addition, there are also such JVMs that support distributed can be considered, don't ask for money :)
Programmatically Controlled Object Lifecycle
This method is the ideal method, the current virtual machine does not have it, it is purely hypothetical. That is: consider programmatically configuring which objects can be skipped directly during garbage collection, reducing the time the garbage collection thread spends traversing markers.
This method is equivalent to telling the virtual machine that some objects can be collected after the * time or can be collected by the code (similar to C, C++) when programming. , he must still be cited.
If the JVM can implement this method, I personally think it will be a leap. Java not only has the advantages of garbage collection, but also has the controllability of C and C++ for memory.
thread allocation
Java's blocking thread model can basically be abandoned, and there are many mature NIO frameworks. The problem with blocking IO is that the number of threads grows linearly, while NIO can be converted into constant threads. Therefore, for server-side applications, NIO is still the only choice. However, can the AIO brought to us in JDK7 make people shine? We will wait and see.
Other JDKs
This article is about Sun's JDK, and the current common JDKs include JRocket and IBM's JDK. Among them, JRocket is much higher than Sun's in terms of IO, but Sun's JDK6.0 has also improved a lot. Moreover, JRocket also has advantages in garbage collection, and it is very attractive to set the maximum pause time for garbage collection. However, after the implementation of the system Sun's G1, there will be a qualitative leap in this regard.
References
Being able to sort out some of the above is also because of standing on the shoulders of giants. The following are some reference materials for everyone to learn, if you have better ones, you can continue to improve :)
Java Theory and Practice: A Brief History of Garbage Collection
· Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning
· Hotspot memory management whitepaper
· Diagnosing a Garbage Collection problem
· Garbage-First Garbage Collection
· Frequently Asked Questions about Garbage Collection in the HotspotTM JavaTM Virtual Machine
· "In-depth Java Virtual Machine" . Although many years have passed, this book is still a classic.
This is the last article in this series, and I'm glad you enjoyed this series of articles. During the period, I also raised a lot of questions, some of which I did not think of or considered inappropriately before. Thanks to the friends who raised these questions, I also learned a lot.