Some tips for memory management in the Java language

What is the impression that the Java system makes? Take up memory! Say this sentence will have more than n people stand up for the Java defense, and a bunch of performance test reports to prove this point.

In fact, in theory, the Java system does not more than other languages developed by the system to occupy memory, then why there are so many n reasons to prove that it does occupy memory? Two words, bad habits.

(1) Do not use the new Boolean ().

Boolean types are required in many scenarios, such as the Boolean set and get in JDBC are passed through a Boolean package, and most ORM encapsulates Boolean types, such as:

Ps.setboolean ("isclosed", New Boolean (true));

Ps.setboolean ("isclosed", New Boolean (isclosed));

Ps.setboolean ("isclosed", New Boolean (i==3));

Typically, the number of Boolean instances constructed in these systems is considerable, so the system is filled with a large number of Boolean instance small objects, which is quite memory-consuming. The Boolean class actually takes only two instances, an instance of true, and an instance of false.

The Boolean class provides two static variables:

public static final Boolean TRUE = new Boolean (true);

public static final Boolean false = new Boolean (false);

Just take these two variables when you need them,

Like what:

Ps.setboolean ("isclosed", boolean.true);

So what if you were to create a Boolean from a Boolean variable like 2 or 3? You can use the static method provided by Boolean: Boolean.valueof ()

Like what:

Ps.setboolean ("isclosed", Boolean.valueof (isclosed));

Ps.setboolean ("isclosed", Boolean.valueof (i==3));

Because the internal implementation of valueof is: return (b?) True:false);

So you can save a lot of memory. It is believed that if the Java specification directly prescribes the Boolean constructor as private, this will never happen again.

(2) Do not use the new Integer.

As with Boolean, there are also a lot of cases in Java development that use integer encapsulation int, and the values usually expressed in int are usually very small. The integer instantiation is optimized in the SUN SDK, the integer class caches 128 to 127 of these 256 states, and if you use integer.valueof (int i), the incoming int range is right here, returning the static instance. This will also greatly reduce memory consumption if we use integer.valueof instead of the new integer. If your system is to be used in a different SDK (such as the IBM SDK), you can do a tool-class encapsulation, such as integerutils.valueof (), so that you can use this feature in any SDK.

(3) using StringBuffer instead of string addition. This I will not say much, because has been spoken n times. I just want to make a joke that is not a joke, I am looking at a domestic "famous" Java development of the source of the web system, unexpectedly found that a large number of the use of string addition, a assembled SQL statements in the method of the most constructed nearly 100 string instances. No words in!

(4) Excessive use of hash tables, developers with certain development experience often use the hash table (a hash table in the JDK is HashMap) to cache some data, thereby increasing the speed of the system. For example, the use of HashMap cache some material information, personnel information and other basic information, which increases the speed of the system also increases the memory footprint of the system, especially when the data is more cached. In fact, we can use the concept of caching in the operating system to solve this problem, that is, to the cached allocation of a certain size of the buffer container, according to a certain algorithm to eliminate the need to continue to cache the object, so on the one hand, because of the object caching and improve the efficiency of the system It also reduces the memory footprint of the system because the cache container is not expanded indefinitely. Now there are many open source cache implementation projects, such as Ehcache, Oscache, and so on, these projects have implemented FIFO, MRU and other common caching algorithms.

(5) Avoid too deep class hierarchies and too deep method calls. Because both of these are very memory-intensive (especially the method invocation is a large consumer of stack space).

(6) A variable is defined and instantiated only when it is used.

(7) Try to avoid the use of static variables, the private constants within the class can be replaced with final.