Because the program to read from the data nearly 10W line records processing, when read to 9W when the Java.lang.OutOfMemoryError:Java heap space such a mistake.
A search on the web may be the reason why the Java stack setting is too small.
According to the answers on the internet, there are roughly two ways to solve this problem:
1. Set environment variable
Set java_opts=-xms32m-xmx512m
You can make changes based on your machine's memory, but I'm not testing this method to solve the problem. There may be a need to set up.
2, java-xms32m-xmx800m ClassName
is to add this parameter when executing the Java class file, where ClassName is required to perform a true class name. (including package name)
This solves the problem. And the speed of execution is much faster than when it is not set.
If you might use Eclispe at the time of the test, you would need to enter-xms32m-xmx800m This parameter in the VM arguments in Eclipse->run-arguments.
Java.lang.OutOfMemoryError:Java Heap Space
===================================================
An exception occurred while querying a large amount of data from a database using a Java program:
Java.lang.OutOfMemoryError:Java Heap Space
This exception information is thrown in the JVM if 98% of the time is for GC and the available HEAP size is less than 2%.
The JVM heap is set up to refer to the set of memory space that the JVM can use to deploy during the runtime of the Java program.
The JVM automatically sets the value of heap size when it starts, and its initial space (that is,-XMS) is 1/64 of the physical memory, and the maximum space (-XMX) is 1/4 of the physical memory. You can use options such as the-XMN-XMS-XMX provided by the JVM to set it up.
For example: java-jar-xmn16m-xms64m-xmx128m Myapp.jar
If the heap size setting is small, in addition to these exception information, you will find that the program's response speed slows down. The GC takes up more time and the application is allocated less execution time.
Heap Size is not greater than 80% of the available physical memory, generally to set the-XMS and-XMX options to the same, and-xmn to the-XMX value of 1/4.
The-XMS-XMN setting for Heap size does not exceed the physical memory size. Otherwise, the "Error occurred during initialization of VM could not reserve enough spaces for object heap" will be prompted.
==========================================================
After one night's effort, I finally finished a program that replaces the specified string, but because I am replacing too many of the total-station HTML files, the bottom of eclipse always reports the Java.lang.OutOfMemoryError:Java after the end of a directory heap The anomaly of space, and then it collapsed.
I think must be frequent operation caused too late to recycle, so after each cycle with a thread.sleep (1000), found or to the directory to die, so the 1000 to 5000, or to die there, I think may not be too late to recycle so simple, perhaps sun JVM is just as likely to not be released in this situation.
Then I added a-xmx256m to the starting parameter, and this time it was OK.
Think about it, or the principle of garbage recycling is not too familiar with the online check, found a few good articles.
Http://java.ccidnet.com/art/3539/20060314/476073_1.html
Http://www.pconline.com.cn/pcedu/empolder/gj/java/0509/701281.html
Also: Java heap management-garbage collection mention a few points, very good, perhaps as a code to write the guidelines:
(1) Do not attempt to assume that garbage collection occurs at the time, all of which are unknown. For example, a temporary object in a method becomes a useless object after the method call completes, and its memory can be freed.
(2) Java provides some classes that deal with garbage collection and provides a way to enforce garbage collection-call System.GC (), but this is also an indeterminate method. Java does not guarantee that the method will be able to start garbage collection every time it is invoked, it simply sends an application to the JVM, whether it really performs garbage collection, and everything is unknown.
(3) Select the appropriate garbage collector. In general, if your system does not have special and demanding performance requirements, you can use the JVM's default options. Otherwise, you might consider using targeted garbage collectors, such as incremental collectors, that are better suited to systems with higher real-time requirements. The system has a high configuration, there are more idle resources, you can consider using parallel tag/purge collector.
(4) The key is also difficult to grasp the problem is a memory leak. Good programming habits and rigorous programming attitude is always the most important, do not let your own a small error caused memory large holes.
(5) Release the reference of the unwanted object as soon as possible.
Most programmers use a temporary variable, is to have the reference variable automatically set to null after exiting the active field (scope), implying that the garbage collector collects the object, and that the referenced object is listening, and if so, remove the listener and then assign a null value.
That is, for the frequent application of memory and free memory operation, or control of their own better, but the System.GC () method does not necessarily apply, preferably using finallize enforcement or write their own finallize methods.
================================================
Tomcat
Encountered a tomcat error: Java.lang.OutOfMemoryError:Java heap space, so looked at the data, found the solution:
If Java runs out of memory, the following error occurs:
Exception in thread "main" Java.lang.OutOfMemoryError:Java heap
Java heap size can be increased as follows:
Java-xms-xmx
Defaults are:
java-xms32m-xmx128m
If you use win
/tomcat/bin/catalina.bat plus the following command:
Set java_opts=-xms32m-xmx256m
If you use Unix/linux
/tomcat/bin/catalina.sh plus the following command:
Java_opts= "-xms32m-xmx256m"