Reprinted from Appendix D from "Java Programming Thoughts"
D.3.3 Special circumstances ■ Strings overhead: String Connection Operator seems simple, but actually consumes a lot of system resources. The compiler can be efficiently connected to the string, but the variable strings require a considerable processor time. For example, suppose S and T are string variables: system.out.println ("Heading" S "Trailer" T); the above statement requires new StringBuffer, string buffer), adds arguments, then use toString ) Convert the result back to a string. Therefore, regardless of disk space or processor time, it will be severely consumed. If you are ready to add multiple strings, consider using a string buffer directly to use a string buffer, especially when you reuse it in a loop. By disable new string buffering in each cycle, save 980 units of object creation time (as mentioned above). The performance can be further improved by using subString () and other string methods. If it is feasible, the speed of the character array can even be faster. It is also necessary to pay attention to the relationship of synchronization, so StringTokenizer will cause greater overhead. ■ Synchronization: In the JDK interpreter, call synchronization methods typically be more slower than that of the call disagreement method. After the JIT compiler is processed, the gap in this performance is raised to 50 to 100 times (note that the previous table summary shows a slow 97 times). So avoid using synchronous methods as much as possible - if you don't avoid it, the synchronization of the method is slightly more faster than the synchronization of the code block. ■ Reuse using objects: Time to get a long time to create a new object (depending on the time summary, the new time of the object is 980 times the assignment time, and the time to create a decimal set is 3100 times). Therefore, the most sensible approach is to save and update the field of old objects, not to create a new object. For example, don't create a new Font object in your own Paint () method. Instead, it should be declared as an example object, and then initialize once. After this, you can update it at any time in Paint (). See "Programming Pickup" edited by Bentley, P.81 [15]. ■ Abnormal: The abnormal processing module should only be discarded in an abnormal case. What is it called "abnormal"? This usually refers to a problem, which is generally unwilling to see, so performance is no longer a priority. When optimizing, the small "try-catch" block is combined together. Since these blocks split the code into small, their independent fragments, it hinders the compiler to optimize. On the other hand, if the excessive is keen to delete an abnormal processing module, it may also cause a decline in code. ■ Hash Treatment: First, the standard "Hashtable" class of Java 1.0 and 1.1 requires shape and synchronization processing of special consumption system resources (assignment time of 570 units). Second, early JDK libraries cannot automatically determine the best form size. Finally, the hash function should be designed for the characteristics of the actual use item (Key). Taking into account all these reasons, we can specifically design a hash class to cooperate with specific applications to improve the performance of conventional listings. Note that the HashMap of the Java 1.2 Collection Library has greater flexibility and will not automatically synchronize. ■ Method embedded: Only the Java compiler can embed this method in the case where the method belongs to Final (final), private (dedicated), or STATIC (static). Moreover, in some cases, it also requires it absolutely not a partial variable.
