Effective Java experience, creating and destroying objects

About effective Java This book, some of his own summary of thinking. The length may not follow the catalogue, because I like to read the first chapter directly. But to be sure, each chapter will have a summary. Welcome everyone to make bricks and add.

1. consider replacing the constructor with a static factory method . Pros: There is a name that does not have to be created every time the object, return any subtype object, concise code. Disadvantage: This class will not be able to quilt class (compound greater than inheritance, is also the advantage), not convenient Doc tool output documents, general conventions of naming rules:

ValueOf conversion Type

GetInstance obtaining an Object instance

Newinstance creating a New object instance

GetType gets the type of the returned object

NewType the type of returned object, which makes it easy to differentiate the factory method in different classes

2. Consider using a builder when you encounter multiple constructor parameters (more than 4). overlapping constructor code lengthy, late can not be effectively maintained, JavaBean mode of the constructor in the multi-threaded insecure, not to achieve class immutability, the reason is to expose the setter method. Builder-mode constructors are a good choice.

Class a{

Property

Static Class bulid{

Property

Bulid () {//Accept initialization Parameters}

Bulid A () {return Bulid;//Add parameter return Bulid generate call chain}

..

A bulid () {return a (this);}//Constructor object initialization A object return

}

A (Bulid b) {//pass the parameters in B to the A parameter field}

}

3. Harden the Singleton property with a private constructor or enumeration type. There are 2 scenarios for private constructors, and exporting instances of static members of a public state with a static factory return private static member instances. But not safe, with AccessibleObject, a private constructor can be called by reflection technology, resulting in a second object, and the solution is to throw an exception when the second instance is generated. Causes singleton serialization, (implementsserializble) + (instance domain transient) + (Readresolve method returns an instance). The single-element enumeration type is the best solution for implementing Singleton.

4. The ability to harden non-instances through a private constructor . Provides a way to construct a display that is better than the compiler provides default, especially a private constructor, and throws Assertionerror in a private constructor. As a result of the use of this technique, the class cannot be made into a quilt.

5. Avoid creating unnecessary objects. consider the direction of the string class, static{} fields, view views (set in map, etc.), auto-boxing unpacking, Object pool.

6. eliminate expired object references. after Stack.pop, the unused element is not empty caused by memory leaks, disk swapping, and severe conditions that cause oom exceptions. Another source of memory leaks is caching issues. If the key is not in the hold reference, then Weakhashmap automatically clears the expired key. If, over time, some keys may not be used, then use Linkedhashmap. The Removeeldestentry method will implement this scenario. The third source is the listener and other callbacks, which are handled using a method that keeps the weak references, that is, the WEAKHASHMAP scheme. A heap profiler for memory leaks.

7. avoid using the finalization method. Finalizer method The JVM does not necessarily execute even if SYSTEM.GC is called. System.runfinalization. Unless you use the System.runfinalizersonexit,runtime.runfinalizersonexit method (Threadstop, it is not recommended). An attempt to use the try{}finally{} structure to display the call finalization method ensures a timely termination. If the subclass overrides the superclass's finalization method, but forgets to call the superclass's finalization method super.finalize manually, the superclass's finalization method will never be called.

What if the contents of this chapter are linked to the actual coding? I also think, because I have little experience in the development of the class library, have not read through the JDK all the source code, so some suggestions are not necessarily accurate.

1. When you create a class, you should think about what this class will do in the future. What type is it? Are there many construction parameters? Applicable experience 1,2,3,4

2. When you write a piece of code, you should think about whether the object can be reused? If it is a collection class, then think about whether the incoming object will not be used in the future? What if you feel this code or method, and that it involves a class that consumes more memory as it runs globally? Then you can try to use 5,6,7 three summary to deal with this problem.

After all, the above are some of the methodology, in the process of practice, it is necessary to have experience to judge how to do is the best (perhaps the current optimal, or the future effect is very good), these are different scenarios produced, and will not necessarily be effective to solve.

Effective Java experience, creating and destroying objects