Garbage collection paradox
The so-called "as also defeated Xiao He." Java's garbage collection does bring a lot of benefits for the development is made easier. But in the case of some high-performance, high-concurrency, garbage collection indeed become a bottleneck of Java applications. Currently JDK garbage collection algorithm, has never been able to solve the problem of garbage collection pause, pause because this has seriously affected the corresponding time of the program, resulting in congestion or accumulation. This is also a follow-up to increase the JDK algorithm G1 important reason.
Of course, the above is from a technical point of view to solve the problems caused by garbage collection, but from the design of the system we need to ask the:
We need to allocate so much memory space to use it?
If we can through the effective use of memory rather than the design of our system by expanding the memory of the way?
We have put the memory of what
What memory need to put it? Personally I think that memory is need to put your application in the near future need to use something again . Think about it, if you do not have these things in the future, why put the memory of it? Put files, databases, not better? These things generally include:
1. business data related to the system is running. For example, web application session, session instant messages. The data typically in a user access cycle or a need to be present during use.
2. Cache. Cache is more and more, you want quick access can be put there. In fact, the above operations can also be understood as a data cache.
3. Thread.
Therefore, we can not think so, if we do not put business data and cache on the JVM, or their independence, the required Java applications use memory will be greatly reduced, and garbage collection time will be reduced .
I think this is possible.
Road solution
Databases, file systems
All the data into a database or file system, which is one of the most simple way. In this manner, Java applications, memory is substantially equal to the processing time required memory peak concurrent requests. Acquired data fetched from the database and the file system on every request. It can also be understood as, after a business visit, all objects can be recovered.
This is a memory using the most efficient way, but from the application point of view, this approach is inefficient.
Memory - Hard map
The above problem is because we use the file system brings inefficient. But if we are not hard to read and write, but to write the words of memory efficiency will improve a lot.
Database and file system are real was persistent, but when we do not need such a persistence, we can do some work - the memory when the hard disk.
Memory - Hard mapped very powerful, not only with the cache memory and has no effect on the use of Java applications. Java applications or Java applications, he only knew of or read-write file, but is actually a memory.
In this way it has both Java applications and cache best of both worlds. It is also widely used memcached this type of representative.
The same machine to deploy multiple JVM
This is a good way, it can be divided into horizontal and vertical split split. Vertical split can be understood as the Java application is divided into different modules, each module uses a separate Java process. And apply the same cross-split function is to deploy multiple JVM.
By deploying multiple JVM, can be put in each JVM memory garbage collection controls a tolerable range. But this is equivalent to a distributed processing, which brings additional complexity is also a need to evaluate. In addition, there are also support distributed JVM that can be considered, not for money, oh :)
Program control of object life cycle
This approach is ideal among the way, the current virtual machine yet, purely hypothetical. Namely: Consider which objects are arranged by the program can skip the garbage collection process, garbage collection thread through the tag to reduce the time.
In this way the equivalent of telling the virtual machine when programming during certain objects you can collect or can collect the identification by the code (similar to C, C ++) * after time, before you even go to traverse He also has no effect he certainly is still being referenced.
If the JVM can be achieved in this way, personally think that would be a leap, Java garbage collection has the advantage of that is, there has been a C, C ++ memory controllability.
Thread allocation
The blocking of Java threading model can basically abandoned, the current framework is also more mature NIO more. Blocking IO problems caused by linear growth is the number of threads, while the NIO can be converted into a constant thread. Therefore, for application server-side, NIO is the only choice. However, JDK7 for us whether the AIO can brighten it? We'll see.
Other JDK
This article says is Sun's JDK, the current common JDK also JRocket and IBM JDK. Which JRocket lot higher than the Sun in terms of IO, but also a great increase after Sun JDK6.0. And JRocket in garbage collection, also has advantages, it can set the maximum pause time garbage collection is also very attractive. However, after the Sun system G1 achieved in this regard will be a qualitative leap.