Constructing high performance J2EE applications not only need to understand commonly used implementation skills. Here is the most commonly used 10 effective methods to help architect designers have quickly become this expert. Java Performance Basics ---- Memory Management Any Java Application, Single Machine or J2EE's performance foundation can be attributed to your application how to manage memory issues. Java's memory management includes two important tasks: memory allocation and memory recycling. In memory allocation, the goal is to reduce the object you need to create. Memory recycling is a universal reason for performance degradation. That is, the more objects in memory, the more difficult garbage recovery. So our attitude towards the creation of objects should be more conservative. The problem related to the two memory common in J2EE applications is: free objects (also known as memory disclosure) and object cycles (refer to a large number of frequent creation and deletion - reflecting in Java to release reference-object). We should take care of ensuring that all reachable objects are actually live, that is, these objects are not only in memory, but also exist in the executed code. When the object is already in the application, we have forgotten the free object when deleting the reference to the object. We know that garbage collection will take up the CPU time. A large number of short-term objects has increased the frequency of garbage recovery. Do not implement business logic in Servlet When building J2EE applications, architecture engineers usually use the basic part of J2EE, servlet. If architect does not use Session Beans, Entity Beans, or Message Beans, the improved performance method is very small. Can only be used to increase CPU or more physical servers. EJB uses a cache and resource pool and other methods to improve performance and scalability. Use the local interface to access EJB in early J2EE (Follow the EJB1.x Specification) application, access EJB is `to use the remote interface through the RMI. With the emergence of EJB2.0, the EJB can be accessed through the local interface, and the RMI is no longer used, and it has been used in the same JVM. But now there are some applications that use EJB1.x and some EJB newers who don't know the use of local interfaces. To illustrate this, we make a comparison: 1. Client application calls local stub2, the Stub assembly parameter 3, the Stub is transmitted to Skeleton4, the Skeleton Decomposing parameter 5, the Skeleton calls EJB object 6, EJB object Execute a container service 7 , EJB Object call Enterprise Bean Instance 8, Enterprise BEA Execution Operation 9, execute the assembly / decomposition step and return to the remote interface processing, the EJB method of the local interface is: 1. Client calling local object 2. Local object Execute a container service 3. Local object call Enterprise Bean Instance 4. Enterprise bean instance execution operation 5. No other return steps! ! If you don't need to access a special EJB from a remote client, you should use your local method. Access to entity EJBs in the service of session beans, accessing entity EJBs from servlet, not only with low efficiency, but also difficult to maintain. Using the Session Facade mode, access packages to entity EJB can be encapsulated in session EJB, and excessive remote calls are avoided in this session EJB to access entity EJBs using local interfaces. This technique will have additional performance and extension benefits because session and entity EJB can be improved using cache and resource pool technology. In addition, due to the need for load, sessions and entity EJBs can be extended to other hardware devices, which is more simple than extending the servlet layer to other hardware devices. Try to access remote EJB as possible When accessing remote EJB, calling the SET / GET method will produce too much network request, and also causing the overload of the remote interface.
