| Programming Skills |
Cause and Policy |
| Avoid repeated object Creation |
Why:
- Fewer objects require less garbage collection.
- The less space the application uses, the better the application performance.
How to do this:
- Reuse an object instead of creating an object with the same functionality every time you need it.
- (In this case)
- String s = "No longer silly ";
- (Not like this)
- String s = new String ("silly ");
- Non-variable classes provide both constructors and static factory methods. The static factory method is preferred.
- Reuse objects that will not change once initialized (using static initialization)
|
| Avoid loop reference |
Why:
- A group of mutually referenced objects will become inaccessible if they are not directly referenced by other objects, which will keep them in the memory.
How to do this:
- You can use strong references to indicate the reference relationship between "Parent and Child", and use weak references to represent the reference relationship between "child and parent.
|
| Use the = Operator to replace the equals (Object) method. |
Why:
- = Operator performance is better
- For example, for string comparison, the equals () method compares characters in string objects. The = Operator compares the references of two objects to determine whether they point to the same instance.
How to do this:
- A. equals (B) is available only when a = B)
- For example, for repeated calls, the static factory method is used to return the same object.
|
| Clear reference of useless objects |
Why:
- Useless object reference will lead to more garbage collection actions, thus reducing performance
- Useless object reference will lead to more memory usage, thus reducing performance
How to do this:
- If a reference is discarded, set it to null.
- (In this case)
-
| 12345678 |
publicObject pop() { if(size == 0) thrownew EmptyStackException(); Object result = elements[--size]; elements[size] = null; // Clear reference of useless objects returnresult;} |
- (Not like this)
-
| 12345 |
publicObject pop(){ if(size == 0) thrownew EmptyStackException(); returnelements[--size];} |
|
| Avoid using finalizer |
Why:
- The garbage collector must separately record the objects waiting for termination.
- Calling the finalize method also has certain overhead.
- Finalizer is insecure because it may have an object revived, which will interfere with garbage collection.
|
| Avoid using reference objects |
Why:
- Like finalizer, the garbage collector must handle soft references, weak references, and ghost references.
- Although the referenced object is very useful in some aspects, such as simplifying the implementation of cache, the existence of a large number of referenced objects will make garbage collection slow.
- The overhead of recording a referenced object far exceeds the overhead of a Common Object (strong reference ).
|
| Avoid using the object pool |
Why:
- The object pool not only keeps more data objects active, but also prolongs the object survival time.
- It is worth noting that the processing of a large number of surviving data objects is the bottleneck of GC, and GC is optimized to be suitable for processing many objects with short lifetime.
- Besides, creating a new object instead of keeping the old object alive will benefit the cache locality.
- However, in an environment that contains a large number of large objects, such as large arrays, the performance may be improved by using the object pool.
|
| Selected algorithms and data structures |
Why:
- Consider the scenario of queue through linked list
- Even if your program does not need to traverse the entire linked list, the garbage collector still needs to do so.
- If the element package does not place the element in the memory, it will damage the cache locality. As a result, the program will be suspended for a long time, especially when the object pointer is scattered in a large heap, the garbage collector will frequently encounter cache failure when following the pointer in the marking stage.
|
| Avoid using System. gc |
Why:
- The Java language specification does not guarantee what will be done by calling System. gc. If it is specified, it may exceed your expectation, or you may do different things each time you call it.
|
| Avoid using too many threads |
Why:
- The number of context switches of a process increases accordingly with the number of processes to be scheduled, which has a potential impact on performance.
- For example, the local thread context on an Intel A-64 processor is about several thousand KB
|
| Avoid using competitive locks |
Why:
- A competitive lock is generally a bottleneck of a program, because its appearance means that multiple threads want to access the same resource or execute the same code.
|
| Avoid unnecessary exceptions |
Why:
- Exception Handling takes up certain events and interrupts the normal execution process of the program.
- In this scenario, a normal execution flow throws thousands of NullPointerException every second in a customer's application. After this error is corrected, the performance of the application is improved by an order of magnitude.
|
| Avoid using large objects |
Why:
- Large objects sometimes need to allocate memory directly in the heap instead of in the thread local Storage Area (TLA.
- Large objects are allocated directly on the stack because it generates memory fragments faster.
- Allocating large objects on a virtual machine (such as JRockit) reduces performance because the heap global lock is used when memory is allocated.
- Excessive use of large objects will cause frequent full-stack compression, which is destructive and will cause all threads to pause for a long time.
|
