358 CHAPTER 14 (Web design course) SOLVING COMMON JAVA EE
358 CHAPTER 14 SOLVING COMMON JAVA EE PERFORMANCE PROBLEMS up, and at some point executes a mark-sweep-compact garbage collection to clean up dead objects as well as to compact live objects at the bottom of the heap. As the heap grows, long- lived objects get pushed to the bottom of the heap. So your best bet for identifying potential memory leaks is to observe the behavior of the heap in its entirety: is the heap trending upward? Resolving Memory Leaks Memory leaks are elusive, but if you can identify the request causing the memory leak, then your work is much easier. Take your application to a development environment, and run it inside a memory profiler, as described in Chapter 5, performing the following steps: 1. Start your application inside the memory profiler. 2. Execute your use case (make the request) once to allow the application to load all of the objects that it needs in memory to satisfy the request; this reduces the amount of noise that you have to sift through later. 3. Take a snapshot of the heap to capture all objects in the heap before the use case has been executed. 4. Execute your use case again. 5. Take another snapshot of the heap to capture all objects in the heap after the use case has been executed. 6. Compare the two snapshots, and look for objects that should not remain in the heap after executing the use case. At this point, you will need access to developers involved in coding the request you are testing, so that they can make a determination about whether an object is, in fact, being leaked or if it is supposed to remain in memory for some purpose. If nothing screams out as a leaked object after performing this exercise, one trick I sometimes use is to perform step 4 a distinct number of times. For example, I might configure my load tester to execute the request 17 times, in hopes that my leak analysis might show 17 instances of something (or some multiple of 17). This technique is not always effective, but it has greatly helped me out when each execution of a request leaks objects. If you cannot isolate the memory leak to a specific request, then you have two options: Profile each suspected request until you find the memory leak. Configure a monitoring tool with memory capabilities. The first option is feasible in a small application or if you were lucky enough to partially isolate the problem, but not very feasible for large applications. The second option is more effective if you can gain access to the monitoring tools. These tools track object creation and destruction counts through bytecode instrumentation and typically report the number of objects held in predefined or user-defined classes, such as the Collections classes, as a result of individual requests. For example, a monitoring tool might report that the /action/login.do request left 100 objects in a HashMap after it completed. This report does not tell you where the memory leak is in the code or the specific object that it leaks, but it tells you, with very low overhead,
If you are looking for cheap and quality webhost to host and run your website check Jboss Web Hosting services.