1. GC generation assumes that the life cycle of most objects is short and survival time is short. So the first thing that the GC algorithm focuses on is these short-lived objects. For applications with low load, the FULLGC phenomenon will not occur. This reminds us that we should shorten the life cycle of the object as much as possible. Some programmers reduce the number of new objects as much as possible, try to reduce the allocation overhead of the heap, and reduce memory fragmentation, but the creation of short-lived objects is better than we expected in the JVM, and the higher the rate at which objects are created, the faster the GC will be triggered! Therefore, the use of stingy new is an unwise choice.
2, Java container is a feature that can be dynamically extended, so usually we do not consider the initial size of the setup, not enough to automatically expand the chant anyway. But expansion does not mean there is no cost, even a high price. For a growing structure, after several expansions, there will be a lot of useless old arrays, and the pressure to reclaim these arrays will all be added to the GC. Container expansion is not to wait until the container is full to expand, but there is a certain proportion. In the Google Guava framework we can pass in the estimated size and the rest is resolved by guava.
3. For object pooling, the only appropriate scenario is that cache reuse makes sense when each object in the pool is expensive to create . Even if you really need to implement an object pool, use a mature open source framework, such as Apache Commons pool. Also, use the threadpoolexecutor of the JDK as the thread pool, and do not create wheels repeatedly.
Java Learning Notes