Memory overflow solution due to application of Jacob components (Java.lang.OutOfMemoryError:Java heap space)

Http://www.educity.cn/wenda/351088.html

Memory overflow solution by using Jacob components (Java.lang.OutOfMemoryError:Java heap space)

All say memory leaks is a common problem of C + +, memory Overflow is Java's mishap, this headache is let me hit. I am doing this function involves modifying the Word document, because Microsoft does not expose the word source code, so directly with the Java stream to read Word's consequences is read out is garbled, after checking the data that can use POI and Jacob to operate word, Jacob is a lot easier to use than a poi, so I chose Jacob,jacob as the abbreviation for Java-com Bridge, which builds a bridge between Java and Microsoft's COM components. Calls to COM programs on the Java platform are implemented using the DLL dynamic-link library of Jacob's own, and by means of the JNI (Java Native Interface java Local call). Because DLL files cannot run on Linux, and clients only interact with Linux, you also need a Windows server that constantly downloads word to each other, with the highest frequency of downloads running up to 100,000 times, and the following are the interaction diagrams between servers:

　　

When the implementation of the function after the test, the result of memory overflow, and then began to make a half-month, check the open stream has not closed, there is no significant use of static variables, there is no large number of string concatenation, Unfortunately did not find out where the problem is (I write the code quality is good), but also try to increase the JVM memory, but to increase the JVM memory can only be a palliative but not a cure, not a reliable way, after extensive access to information, learned that COM thread recycling is not handled by the Java garbage collector, therefore, Each new time Jacob provides a class to allocate a certain amount of memory to the operation, new COM object generated after the end of the garbage Java is not recyclable, new objects are more and more, memory overflow is unavoidable, even if the JVM memory is only temporary to increase, Sooner or later these objects will run out of memory. Since Java cannot reclaim this garbage, then COM components should also provide a way to recycle garbage, and finally know that it is the Comthread.initsta () and Comthread.release () methods, both of which are actually initializing a thread and ending this thread, When creating a COM object to initialize a thread to run this object, the object used to end the thread after the end, the problem is resolved, the program running one or two days of memory has been very smooth, the problem of fast one months finally solved, the following is all the code:

　　/** * @fileName Mswordmanager.java * @description This class is used to find the Word document at the specified location and insert the picture * @date 2011-10-21 * @time * @author WST */Pub Lic class Mswordmanager {private Logger log = Logger.getlogger (mswordmanager.class);//Word document private Dispatch doc;//W Ord Run Program object Private activexcomponent Word; All Word Document collections private Dispatch documents; The selected range or insertion point is private Dispatch selection; public static int instancesize=3;//A thread holds the number of Mswordmanager public mswordmanager (int index) {if (word = = null) {word = new Activexcomponent ("Word.Application"); True indicates that the Word application is visible word.setproperty ("visible", new Variant (false)); } if (documents = = NULL) {documents = Word.getproperty ("Documents"). Todispatch ();} if (index==0) {Comthread.initsta ();// Initialize a thread and put it in memory to wait for the call}}/** * Open an existing document * @param docPath the document to open * @param the contents of the Key text box, get the current position of the text box according to the key * @date 2011-12-9 * @a Uthor WST */public void Opendocumentandgetselection (string docPath, String key) {try{closedocument ()//Open doc = Disp Atch.call (Documents, "Open", DocPath).Todispatch (); Shapes collection Dispatch shapes = Dispatch.get (doc, "Shapes"). Todispatch (); Number of shapes String Count = dispatch.get (Shape, "Count"). ToString (); for (int i = 1; I <= integer.parseint (Count); i++) {//Get a shape Dispatch shape = dispatch.call (shapes, "Item", New Va Riant (i)). Todispatch (); Gets the text box from a shape inside Dispatch textframe = dispatch.get (Shape, "TextFrame"). Todispatch (); Boolean hasText = Dispatch.call (TextFrame, "HasText"). ToBoolean (); if (hasText) {//Gets the text box object Dispatch TextRange = Dispatch.get (TextFrame, "TextRange"). Todispatch (); Gets the string in the text box. R = Dispatch.get (TextRange, "Text"). ToString (); Gets the position of the text box where the specified character key is located if (str! = null &&!str.equals ("") && Str.indexof (Key) >-1) {//The position of the current text box Selectio n = dispatch.get (TextFrame, "TextRange"). Todispatch (); Case text Box Contents Dispatch.put (Selection, "Text", ""); Break }}}}catch (Exception e) {log.error (e); return;}} /** * Insert Picture at current position * @param imagePath the path to the picture * @return success: TRUE; Failed: false */Public Boolean INsertimage (String imagePath) {try{Dispatch.call (Dispatch.get (Selection, "InlineShapes"). Todispatch (), "AddPicture" , ImagePath); }catch (Exception e) {log.error (e); return false;} return true; }//Close document public void Closedocument () {if (doc! = null) {Dispatch.call (doc, "close"); doc = null;}}//Close all application public voi D Close (int index) {if (Word = null) {Dispatch.call (Word, "Quit"); word = null;} selection = null; documents = NULL; F (index==instancesize) {//frees occupied memory space because COM thread recycling is not handled by the Java Garbage Collector Comthread.release ();}} }

The problem is solved, although the Java program written is not a problem, but also learned some how to prevent memory overflow knowledge, below to see I found in the network of several common memory overflow and how to detect memory overflow and out of the way.

　　First, Several typical memory leaks

We know there is a memory leak in Java, so let's take a look at a few typical leaks and find out why and how they're going to work.  
1  Global Collection  
It is common to have a wide variety of global data warehouses in large applications. Like a jndi-tree or a session table. In these cases, you must be aware of the size of the management repository. There must be some mechanism to remove data that is no longer needed from the repository.  
There are often many different forms of resolution, the most common of which is a cycle-run cleanup job. This job verifies the data in the warehouse and clears all the data that is not needed.  
Another way to manage repositories is to use the reverse link (referrer) count. The collection is then responsible for counting the number of backlinks for each entry in the collection. This requires a reverse link to tell the collection when the entry exits. When the number of backlinks is zero, the element can be removed from the collection.  
2  cache  
caches a data structure that is used to quickly find the results of an operation that has been performed. Therefore, if an operation executes a resource that requires more resources and is used more than once, it is common practice to cache the results of the operations of the commonly used input data in order to use the cached data the next time the operation is invoked. Caches are usually implemented dynamically, and if the cache settings are incorrect and the cache is heavily used, the result is a memory overflow, so you need to balance the amount of memory used with the speed at which data is retrieved.  
The common solution is to use the Java.lang.ref.SoftReference class to persist objects into the cache. This method ensures that when a virtual machine runs out of memory or needs more heaps, it can release references to those objects.  
3  class loader  
The use of the Java class Loader provides a lot of opportunity for memory leaks. The class loader generally has a complex structure, because the class loader is not just about "general" object references, but also about references inside objects. such as data variables, methods, and various classes. This means that as long as there is a class loader for data variables, methods, classes, and objects, the class loader will reside in the JVM. Since class loaders can be associated with many classes and can also be associated with static data variables, a significant amount of memory can leak.

　　 Second,how to detect and handle memory leaks
How to find the cause of a memory leak generally there are two steps: The first is to arrange for experienced programmers to walk through and analyze the code to find out where the memory leak occurred, and the second is to use a dedicated memory leak test tool to test.
The first step in the work of code walk, you can arrange for the system business and development language tools familiar to the developer of the application of the code to cross-check, try to find out the code in the database connection declaration and result set is not closed, code redundancy and other failure codes.
The second step is to detect a Java memory leak. Here we usually use some tools to check the memory leak of Java programs. There are several professional tools on the market to check the Java memory leaks, they basically work the same principle, all through the monitoring of the Java program runtime, all object application, release and other actions, the memory management of all the information to statistical, analysis, visualization. The developer will use this information to determine if the program has a memory leak problem. These tools include Optimizeit Profiler,jprobe profiler,jinsight, Rational company Purify, etc.
1detecting the presence of memory leaks
Here we will briefly describe the process in which we use the Optimizeit check. Usually, after knowing that a memory leak occurs, the first step is to figure out what data was leaking and which class of objects caused the leak.
Generally speaking, a normal system after its stable operation of its memory consumption is basically stable, should not be unrestricted growth. Similarly, there is a relatively stable upper limit on the number of objects used for any one class, and should not be continuously growing. Based on this basic assumption, we continuously observe the size of the memory used by the system and the number of instances, and if the size of the memory continues to grow, there is a memory leak in the system, if the number of instance objects for a particular class grows over time (that is, the so-called "growth rate"). Indicates that an instance of this class might have a leak condition.
On the other hand, the first sign of a memory leak usually occurs is outofmemoryerror in the application. In this case, you need to use some of the less expensive tools to monitor and find memory leaks. While it is possible that the application is actually using so much memory, OutOfMemoryError can increase the number of heaps available to the JVM, or make some changes to the application so that it uses less memory.
However, in many cases, outofmemoryerror are signals of memory leaks. One way to find out is to continuously monitor GC activity to determine if memory usage increases over time. If this is the case, a memory leak may occur.

　　2 ways to handle memory leaks

Once you know that a memory leak does occur, you need a more professional tool to find out why the leak occurred. The JVM is not going to tell you. There are basically two ways these professional tools get memory system information from the JVM: JVMTI and Bytecode Technology (byte code instrumentation). Java Virtual Machine Tool interface (Java VM Tools INTERFACE,JVMTI) and its predecessor Java hypervisor interface (Java virtual machines Profiling Interface, JVMPI) is a standardized interface for external tools to communicate with the JVM and collect information from the JVM. Bytecode technology refers to the technique of using a probe to process bytecode to obtain the information needed by the tool.
Optimizeit is a product of Borland, which is primarily used to assist in code optimization and fault diagnosis of software systems, where the Optimizeit Profiler is primarily used for memory leak analysis. The heap view of profiler is used to observe the size of memory used by the system and the number of instances allocated for each class.
First, the profiler will perform a trend analysis to find out which class of objects are leaking. Four memory snapshots can be obtained after the system has been running for a long time. A comprehensive analysis of these four memory snapshots, if the memory usage of each snapshot is higher than the last time, it can be assumed that the system has a memory leak, to find out in four snapshots of the number of instances to maintain the growth of classes, these classes can be initially identified as a leak. Through data collection and preliminary analysis, it can be concluded that there is a memory leak in the system and which objects are leaking (leaked).
Next, look at what other classes are associated with the objects of the leaking class. The memory leaks in Java have been mentioned as useless object-keeping, simply because the coding error resulted in the existence of a reference chain that should not have existed (which caused the referenced object to be unable to be freed), so the task of memory leak analysis was to find out the redundant reference chain and find out the reason for its formation. It is useful to see where objects are assigned. It is not enough to know just how they are associated with other objects (that is, which objects reference them), and it is also useful for information about where they are created.
Finally, explore the individual objects to see how they relate to each other. With the profiler tool, code in your application can be dynamically added at allocation time to create a stack trace. There is also a dynamic stack trace that can be assigned to all objects in the system. These stack traces can be accumulated and analyzed in the tool. For each leaked instance object, there must be a chain of references from a traction object that arrives at the object. The traction object in the stack space loses its traction after being ejected from the stack and becomes a non-traction object. Therefore, after a long run, the object being leaked is basically drawn by the traction object as the static variable of the class.
In a word, although Java has the function of automatically reclaiming and managing memory, memory leaks are not negligible, it is often an important factor that destroys the stability of the system.

Memory overflow solution due to the application of Jacob components (Java.lang.OutOfMemoryError:Java heap space)