If you keep on allocating & keeping references to object, you will fill up any amount of memory you have.
One option is to do a transparent file close & open when they switch tabs (you only keep a pointer to the file, and when the user switches tab, you close & clean all the objects… it’ll make the file change slower… but…), and maybe keep only 3 or 4 files on memory.
Other thing you should do is, when the user opens a file, load it, and intercept any OutOfMemoryError, then (as it is not possible to open the file) close that file, clean its objects and warn the user that he should close unused files.
Your idea of dynamically extending virtual memory doesn’t solve the issue, for the machine is limited on resources, so you should be carefull & handle memory issues (or at least, be carefull with them).
A couple of hints i’ve seen with memory leaks is:
—> Keep on mind that if you put something into a collection and afterwards forget about it, you still have a strong reference to it, so nullify the collection, clean it or do something with it… if not you will find a memory leak difficult to find.
—> Maybe, using collections with weak references (weakhashmap…) can help with memory issues, but you must be carefull with it, for you might find that the object you look for has been collected.
—> Another idea i’ve found is to develope a persistent collection that stored on database objects least used and transparently loaded. This would probably be the best approach…
- Upto my knowledge, Heap space is occupied by instance variables only. If this is correct, then why this error occurred after running fine for sometime as space for instance variables are alloted at the time of object creation.
That means you are creating more objects in your application over a period of time continuously. New objects will be stored in heap memory and that’s the reason for growth in heap memory.
Heap not only contains instance variables. It will store all non-primitive data types ( Objects). These objects life time may be short (method block) or long (till the object is referenced in your application)
- Is there any way to increase the heap space?
Yes. Have a look at this oracle article for more details.
There are two parameters for setting the heap size:
-Xms:, which sets the initial and minimum heap size
-Xmx:, which sets the maximum heap size
- What changes should I made to my program so that It will grab less heap space?
It depends on your application.
-
Set the maximum heap memory as per your application requirement
-
Don’t cause memory leaks in your application
-
If you find memory leaks in your application, find the root cause with help of profiling tools like MAT, Visual VM , jconsole etc. Once you find the root cause, fix the leaks.
Important notes from oracle article
Cause: The detail message Java heap space indicates object could not be allocated in the Java heap. This error does not necessarily imply a memory leak.
Possible reasons:
- Improper configuration ( not allocating sufficiant memory)
- Application is unintentionally holding references to objects and this prevents the objects from being garbage collected
- Applications that make excessive use of finalizers. If a class has a finalize method, then objects of that type do not have their space reclaimed at garbage collection time. If the finalizer thread cannot keep up, with the finalization queue, then the Java heap could fill up and this type of OutOfMemoryError exception would be thrown.
On a different note, use better Garbage collection algorithms ( CMS or G1GC)
Have a look at this question for understanding G1GC
- Upto my knowledge, Heap space is occupied by instance variables only. If this is correct, then why this error occurred after running fine for sometime as space for instance variables are alloted at the time of object creation.
That means you are creating more objects in your application over a period of time continuously. New objects will be stored in heap memory and that’s the reason for growth in heap memory.
Heap not only contains instance variables. It will store all non-primitive data types ( Objects). These objects life time may be short (method block) or long (till the object is referenced in your application)
- Is there any way to increase the heap space?
Yes. Have a look at this oracle article for more details.
There are two parameters for setting the heap size:
-Xms:, which sets the initial and minimum heap size
-Xmx:, which sets the maximum heap size
- What changes should I made to my program so that It will grab less heap space?
It depends on your application.
-
Set the maximum heap memory as per your application requirement
-
Don’t cause memory leaks in your application
-
If you find memory leaks in your application, find the root cause with help of profiling tools like MAT, Visual VM , jconsole etc. Once you find the root cause, fix the leaks.
Important notes from oracle article
Cause: The detail message Java heap space indicates object could not be allocated in the Java heap. This error does not necessarily imply a memory leak.
Possible reasons:
- Improper configuration ( not allocating sufficiant memory)
- Application is unintentionally holding references to objects and this prevents the objects from being garbage collected
- Applications that make excessive use of finalizers. If a class has a finalize method, then objects of that type do not have their space reclaimed at garbage collection time. If the finalizer thread cannot keep up, with the finalization queue, then the Java heap could fill up and this type of OutOfMemoryError exception would be thrown.
On a different note, use better Garbage collection algorithms ( CMS or G1GC)
Have a look at this question for understanding G1GC
Разбираем частые ошибки ЕГАИС.
Ошибка 1. Проблемы работы с Интернетом, приходит уведомление «Превышено время ожидания». В таком случае, достаточно перезапустить УТМ.
Ошибка 2. Документы в ЕГАИС медленно обрабатываются или вовсе не загружаются.
Очистите базу УТМ, для этого необходимо остановить службу УТМ. После удалить папку «transportDB» по пути «C:UTMtransporter».
Ошибка 3. Периодически в ответ на исходящую ТТН возвращается тикет с комментарием «Java heap space»
Проверьте в логах УТМ следующие ошибки:
Ошибка проверки RSA сертификата
ERROR ru.centerinform.transport.backbone.schedule.RSACertVerificationJob
Количество выделяемой памяти
java.lang.OutOfMemoryError: Java heap space
Чтобы устранить ошибку в УТМ нужно изменить параметр Java:
- Остановите службу транспортного модуля
- Сохраните отдельно оригинал «Install.bat»
- Удалите службу УТМ «Uninstall.bat»
- Измените в Install.bat параметры —JvmMs 500 —JvmMx 1000 (добавлять нужно после —JvmOptions)
- После запустите Install.bat, чтобы установить службу с новым параметром. Установка и удаление службы производится из папки C:UTMtransporterbin
Напоминаем, что нужно вовремя обновлять УТМ. Версия вашего УТМ должна быть не ниже 4.2.0 b2470. Версии модуля ниже b2470 могут работать некорректно.
Overview
An out of memory error in Java formally known as java.lang.OutOfMemoryError is a runtime error that occurs when the Java Virtual Machine (JVM) cannot allocate an object in the Java heap memory. In this article, we will be discussing several reasons behind “out of memory” errors in Java and how you can avoid them.
The JVM manages the memory by setting aside a specific size of the heap memory to store the newly allocated objects. All the referenced objects remain active in the heap and keep that memory occupied until their reference is closed. When an object is no longer referenced, it becomes eligible to be removed from the heap by the Garbage collector to free up the occupied heap memory. In certain cases, the Java Garbage Collector (GC) is unable to free up the space required for a new object and the available heap memory is insufficient to support the loading of a Java class, this is when an “out of memory” error occurs in Java.
What causes the out of memory error in Java?
An “out of memory” error in Java is not that common and is a direct indication that something is wrong in the application. For instance, the application code could be referencing large objects for too long that is not required or trying to process large amounts of data at a time. It is even possible that the error could have nothing to do with objects on the heap and the reason behind it like because of third-party libraries used within an application or due to an application server that does not clean up after deployment.
Following are some of the main causes behind the unavailability of heap memory that cause the out of memory error in Java.
· Java heap space error
It is the most common out of memory error in Java where the heap memory fills up while unable to remove any objects.
See the code snippet below where java.lang.OutOfMemoryError is thrown due to insufficient Java heap memory available:
public class OutOfMemoryError01 {
public static void main(String[] args) {
Integer[] arr = new Integer[1000 * 1000 * 1000];
}
}
Output:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at OutOfMemoryErrorExample.main(OutOfMemoryErrorExample.java:8)
In the above code, an array of integers with a very large size is attempted to be initialized. As the Java heap is insufficient to allocate such a huge array, it will eventually throw a java.lang.OutOfMemoryError: Java heap space error. Initially, it might seem fine but over time, it will result in consuming a lot of Java heap space and when it fills all of the available memory in the heap, Garbage Collection will not be able to clean it as the code would still be in execution and the no memory can be freed.
Another reason for a Java heap space error is the excessive use of finalizers. If a class has a finalize() method, the GC will not clean up any objects of that class, instead, they all will be queued up for finalization at a later stage. If a finalizer thread cannot keep up with the finalization queue because of excessive usage of finalizers, the Java heap will eventually fill up resulting in an “out of memory” error in Java.
Prevention:
Developers need to use the finalize methods only when required and they must monitor all the objects for which finalization would be pending.
· GC Overhead limit exceeded:
This error indicates that the garbage collector is constantly running due to which the program will also be running very slowly. In a scenario where for minimum consecutive 5 garbage collection cycles, if a Java process utilizes almost 98% of its time for garbage collection and could recover less than 2% of the heap memory then a Java Out of Memory Error will be thrown.
This error typically occurs because the newly generated data could barely fit into the Java heap memory having very little free space for new object allocations.
Prevention:
Java developers have the option to set the heap size by themselves. To prevent this error, you must Increase the heap size using the -Xmx attribute when launching the JVM.
· PermGen space error:
JVM separates the memory into different sections. One of the sections is Permanent Generation (PermGen) space. It is used to load the definitions of new classes that are generated at the runtime. The size of all these sections, including the PermGen area, is set at the time of the JVM launch. If you do not set the sizes of every area yourself, platform-specific defaults sizes will be then set. If the Permanent Generation’s area is ever exhausted, it will throw the java.lang.OutOfMemoryError: PermGen space error.
Prevention:
The solution to this out of Memory Error in Java is fairly simple. The application just needs more memory to load all the classes to the PermGen area so just like the solution for GC overhead limit exceeding error, you have to increase the size of the PermGen region at the time of Java launch. To do so, you have to change the application launch configuration and increase or if not used, add the –XX:MaxPermSize parameter to your code.
· Out of MetaSpace error:
All the Java class metadata is allocated in native memory (MetaSpace). The amount of MetaSpace memory to be used for class metadata is set by the parameter MaxMetaSpaceSize. When this amount exceeds, a java.lang.OutOfMemoryError exception with a detail MetaSpace is thrown.
Prevention:
If you have set the MaxMetaSpaceSize on the command line, increasing its size manually can solve the problem. Alternatively, MetaSpace is allocated from the same address spaces as the Java heap memory so by reducing the size of the Java heap, you can automatically make space available for MetaSpace. It should only be done when you have excess free space in the Java heap memory or else you can end up with some other Java out of memory error.
· Out of swap space error:
This error is often occurred due to certain operating system issues, like when the operating system has insufficient swap space or a different process running on the system is consuming a lot of memory resources.
Prevention:
There is no way to prevent this error as it has nothing to do with heap memory or objects allocation. When this error is thrown, the JVM invokes the error handling mechanism for fatal errors. it generates an error log file, which contains all the useful information related to the running threads, processes, and the system at the time of the crash. this log information can be very useful to minimize any loss of data.
How to Catch java.lang.OutOfMemoryError?
As the java.lang.OutOfMemoryError is part of the Throwable class, it can be caught and handled in the application code which is highly recommended. The handling process should include the clean up the resources, logging the last data to later identify the reason behind the failure, and lastly, exit the program properly.
See this code example below:
public class OutOfMemoryError02 {
public void createArr (int size) {
try {
Integer[] myArr = new Integer[size];
} catch (OutOfMemoryError ex) {
//creating the Log
System.err.println("Array size is too large");
System.err.println("Maximum JVM memory: " +
Runtime.getRuntime().maxMemory());
}
}
public static void main(String[] args) {
OutOfMemoryError02 oomee = new OutOfMemoryError02();
ex.createArr (1000 * 1000 * 1000);
}
}
In the above code, as the line of code that might cause an out of Memory Error is known, it is handled using a try-catch block. In case, if the error occurs, the reason for the error will be logged that is the large size of the array and the maximum size of the JVM, which will be later helpful for the caller of the method to take the action accordingly.
In case of an out of memory error, this code will exit with the following message:
Array size is too large Maximum JVM memory: 9835679212
It is also a good option to handle an out of Memory Error in Java when the application needs to stay in a constant state in case of the error. This allows the application to keep running normally if any new objects are not required to be allocated.
See Also: CompletableFuture In Java With Examples
Conclusion
In this article, we have extensively covered everything related to the “out of memory” error in Java. In most cases, you can now easily prevent the error or at least will be able to retrieve the required information after the crashing of the program to identify the reason behind it. Managing errors and exceptions in your code is always challenging but being able to understand and avoid these errors can help you in making your applications stable and robust.
java.lang.OutOfMemoryError:
Java heap space
Java applications are only allowed to use a limited amount of memory. This limit is specified during application startup. To make things more complex, Java memory is separated into two different regions. These regions are called Heap space and Permgen (for Permanent Generation):
The size of those regions is set during the Java Virtual Machine (JVM) launch and can be customized by specifying JVM parameters -Xmx and -XX:MaxPermSize. If you do not explicitly set the sizes, platform-specific defaults will be used.
The java.lang.OutOfMemoryError: Java heap space error will be triggered when the application attempts to add more data into the heap space area, but there is not enough room for it.
Note that there might be plenty of physical memory available, but the java.lang.OutOfMemoryError: Java heap space error is thrown whenever the JVM reaches the heap size limit.
What is causing it?
There most common reason for the java.lang.OutOfMemoryError: Java heap space error is simple – you try to fit an XXL application into an S-sized Java heap space. That is – the application just requires more Java heap space than available to it to operate normally. Other causes for this OutOfMemoryError message are more complex and are caused by a programming error:
- Spikes in usage/data volume. The application was designed to handle a certain amount of users or a certain amount of data. When the number of users or the volume of data suddenly spikes and crosses that expected threshold, the operation which functioned normally before the spike ceases to operate and triggers the java.lang.OutOfMemoryError: Java heap space error.
- Memory leaks. A particular type of programming error will lead your application to constantly consume more memory. Every time the leaking functionality of the application is used it leaves some objects behind into the Java heap space. Over time the leaked objects consume all of the available Java heap space and trigger the already familiar java.lang.OutOfMemoryError: Java heap space error.
Give me an example
Trivial example
The first example is truly simple – the following Java code tries to allocate an array of 2M integers. When you compile it and launch with 12MB of Java heap space (java -Xmx12m OOM), it fails with the java.lang.OutOfMemoryError: Java heap space message. With 13MB Java heap space the program runs just fine.
class OOM {
static final int SIZE=2*1024*1024;
public static void main(String[] a) {
int[] i = new int[SIZE];
}
}
Memory leak example
The second and a more realistic example is of a memory leak. In Java, when developers create and use new objects e.g. new Integer(5), they don’t have to allocate memory themselves – this is being taken care of by the Java Virtual Machine (JVM). During the life of the application the JVM periodically checks which objects in memory are still being used and which are not. Unused objects can be discarded and the memory reclaimed and reused again. This process is called Garbage Collection. The corresponding module in JVM taking care of the collection is called the Garbage Collector (GC).
Java’s automatic memory management relies on GC to periodically look for unused objects and remove them. Simplifying a bit we can say that a memory leak in Java is a situation where some objects are no longer used by the application but Garbage Collection fails to recognize it. As a result these unused objects remain in Java heap space indefinitely. This pileup will eventually trigger the java.lang.OutOfMemoryError: Java heap space error.
It is fairly easy to construct a Java program that satisfies the definition of a memory leak:
class KeylessEntry {
static class Key {
Integer id;
Key(Integer id) {
this.id = id;
}
@Override
public int hashCode() {
return id.hashCode();
}
}
public static void main(String[] args) {
Map m = new HashMap();
while (true)
for (int i = 0; i < 10000; i++)
if (!m.containsKey(new Key(i)))
m.put(new Key(i), "Number:" + i);
}
}
When you execute the above code above you might expect it to run forever without any problems, assuming that the naive caching solution only expands the underlying Map to 10,000 elements, as beyond that all the keys will already be present in the HashMap. However, in reality the elements will keep being added as the Key class does not contain a proper equals() implementation next to its hashCode().
As a result, over time, with the leaking code constantly used, the “cached” results end up consuming a lot of Java heap space. And when the leaked memory fills all of the available memory in the heap region and Garbage Collection is not able to clean it, the java.lang.OutOfMemoryError:Java heap space is thrown.
The solution would be easy – add the implementation for the equals() method similar to the one below and you will be good to go. But before you manage to find the cause, you will definitely have lose some precious brain cells.
@Override
public boolean equals(Object o) {
boolean response = false;
if (o instanceof Key) {
response = (((Key)o).id).equals(this.id);
}
return response;
}What is the solution?
In some cases, the amount of heap you have allocated to your JVM is just not enough to accommodate the needs of your applications running on that JVM. In that case, you should just allocate more heap – see at the end of this chapter for how to achieve that.
In many cases however, providing more Java heap space will not solve the problem. For example, if your application contains a memory leak, adding more heap will just postpone the java.lang.OutOfMemoryError: Java heap space error. Additionally, increasing the amount of Java heap space also tends to increase the length of GC pauses affecting your application’s throughput or latency.
If you wish to solve the underlying problem with the Java heap space instead of masking the symptoms, you need to figure out which part of your code is responsible for allocating the most memory. In other words, you need to answer these questions:
- Which objects occupy large portions of heap
- where these objects are being allocated in source code
At this point, make sure to clear a couple of days in your calendar (or – see an automated way below the bullet list). Here is a rough process outline that will help you answer the above questions:
- Get security clearance in order to perform a heap dump from your JVM. “Dumps” are basically snapshots of heap contents that you can analyze. These snapshot can thus contain confidential information, such as passwords, credit card numbers etc, so acquiring such a dump might not even be possible for security reasons.
- Get the dump at the right moment. Be prepared to get a few dumps, as when taken at a wrong time, heap dumps contain a significant amount of noise and can be practically useless. On the other hand, every heap dump “freezes” the JVM entirely, so don’t take too many of them or your end users start facing performance issues.
- Find a machine that can load the dump. When your JVM-to-troubleshoot uses for example 8GB of heap, you need a machine with more than 8GB to be able to analyze heap contents. Fire up dump analysis software (we recommend Eclipse MAT, but there are also equally good alternatives available).
- Detect the paths to GC roots of the biggest consumers of heap. We have covered this activity in a separate post here. It is especially tough for beginners, but the practice will make you understand the structure and navigation mechanics.
- Next, you need to figure out where in your source code the potentially hazardous large amount of objects is being allocated. If you have good knowledge of your application’s source code you’ll be able to do this in a couple searches.
Alternatively, we suggest Plumbr, the only Java monitoring solution with automatic root cause detection. Among other performance problems it catches all java.lang.OutOfMemoryErrors and automatically hands you the information about the most memory-hungry data structres.
Plumbr takes care of gathering the necessary data behind the scenes – this includes the relevant data about heap usage (only the object layout graph, no actual data), and also some data that you can’t even find in a heap dump. It also does the necessary data processing for you – on the fly, as soon as the JVM encounters an java.lang.OutOfMemoryError. Here is an example java.lang.OutOfMemoryError incident alert from Plumbr:
Without any additional tooling or analysis you can see:
- Which objects are consuming the most memory (271 com.example.map.impl.PartitionContainer instances consume 173MB out of 248MB total heap)
- Where these objects were allocated (most of them allocated in the MetricManagerImpl class, line 304)
- What is currently referencing these objects (the full reference chain up to GC root)
Equipped with this information you can zoom in to the underlying root cause and make sure the data structures are trimmed down to the levels where they would fit nicely into your memory pools.
However, when your conclusion from memory analysis or from reading the Plumbr report are that memory use is legal and there is nothing to change in the source code, you need to allow your JVM more Java heap space to run properly. In this case, alter your JVM launch configuration and add (or increase the value if present) the following:
-Xmx1024m
The above configuration would give the application 1024MB of Java heap space. You can use g or G for GB, m or M for MB, k or K for KB. For example all of the following are equivalent to saying that the maximum Java heap space is 1GB:
java -Xmx1073741824 com.mycompany.MyClass
java -Xmx1048576k com.mycompany.MyClass
java -Xmx1024m com.mycompany.MyClass
java -Xmx1g com.mycompany.MyClass
В JVM, если 98% времени используется для GC (сборка мусора) и доступный размер кучи меньше 2%, будет выдано сообщение об исключении java.lang.OutOfMemoryError: Java heap space.
Итак, обычно есть две причины этой аномалии:
1. В программе есть бесконечный цикл.
2. Программа занимает слишком много памяти, что превышает максимальное значение, установленное кучей JVM.
В первом случае вам необходимо самостоятельно проверить программный код, поэтому я не буду здесь говорить больше.
Во втором случае мы вручную расширяем настройки параметров кучи JVM. Настройка кучи JVM относится к настройке пространства памяти, которое JVM может выделить и использовать во время выполнения программы java. Когда JVM запускается, куча JVM автоматически устанавливает значение размера кучи. Обычно значение по умолчанию для начального пространства (например, -Xms) составляет 1/64 физической памяти, а максимальное пространство составляет 1/4 физической памяти. Его можно установить с помощью таких параметров, как -Xmn -Xms -Xmx, предоставляемых JVM. Вот объяснение значения каждого параметра:
-Xms: начальное значение
-Xmx: максимум
-Xmn: минимальное значение
Размер кучи не должен быть слишком маленьким или слишком большим. Если параметр слишком мал, скорость отклика программы будет ниже, потому что сборщик мусора занимает больше времени, а приложение выделяет меньше времени на выполнение. Слишком большой размер также приведет к потере места и повлияет на нормальную работу других программ. Размер кучи не должен превышать 80% доступной физической памяти. Рекомендуется установить одинаковые параметры -Xms и -Xmx, а -Xmn составляет 1/4 значения -Xmx.
Основные методы настройки следующие:
1. Этот параметр добавляется при выполнении файла класса JAVA, где className – это имя класса, который необходимо выполнить. (Включая имя пакета) Например: java -Xms32m -Xmx800m className Это не только решает проблему, но и скорость выполнения намного выше, чем когда она не установлена. Если это тест разработки, вы также можете установить его прямо в eclipse. Введите -Xms32m -Xmx800m в аргументы виртуальной машины в Eclipse -> run -arguments.
2. Вы можете изменить системные переменные среды в Windows и добавить JAVA_OPTS = -Xms64m -Xmx512m.
3. Если вы используете tomcat под окнами, вы можете добавить в C: tomcat5.5.9 bin catalina.bat (конкретный путь зависит от местоположения вашего tomcat): установить JAVA_OPTS = -Xms64m -Xmx256m (размер зависит от вашей собственной памяти) Местоположение: rem Угадайте CATALINA_HOME, если не определено Добавьте соответствующее в этой строке.
4. Если это система Linux, добавьте набор JAVA_OPTS = ’- Xms64 -Xmx512’ перед {tomcat_home} /bin/catalina.sh
Поскольку программе необходимо прочитать около 10 Вт строк записей из данных для обработки, возникает ошибка типа java.lang.OutOfMemoryError: пространство кучи Java появляется при чтении 9 Вт.
Проверка в Интернете может быть причиной того, что параметр стека JAVA слишком мал.
Согласно ответам в Интернете, существует примерно два решения:
1. Задайте переменные среды.
set JAVA_OPTS= -Xms32m -Xmx512m
можно изменить в соответствии с объемом памяти вашего компьютера, но моя проверка этого метода не решила проблему. Это может быть где еще нужно установить.
2、java -Xms32m -Xmx800m className
– добавить этот параметр при выполнении файла класса JAVA, где className – это фактическое имя класса, который должен быть выполнен. (Включая название пакета)
Это решает проблему. И скорость выполнения намного выше, чем без настройки.
Если вы можете использовать Eclispe при тестировании, вам необходимо ввести параметр -Xms32m -Xmx800m в аргументы виртуальной машины в Eclipse -> run -arguments.
java.lang.OutOfMemoryError: Java heap space
Исключение возникает при использовании программы Java для запроса большого количества данных из базы данных:
java.lang.OutOfMemoryError: Java heap space
В JVM, если 98% времени используется для сборки мусора, а доступный размер кучи меньше 2%, будет выдано это сообщение об исключении.
Настройка кучи JVM относится к настройке пространства памяти, которое JVM может выделить и использовать во время выполнения программы java.
JVM автоматически установит значение размера кучи при запуске.Его начальное пространство (-Xms) составляет 1/64 физической памяти, а максимальное пространство (-Xmx) – 1/4 физической памяти. Его можно установить с помощью таких параметров, как -Xmn -Xms -Xmx, предоставляемых JVM.
Например: java -jar -Xmn16m -Xms64m -Xmx128m MyApp.jar
Если размер кучи установлен слишком маленьким, в дополнение к этим аномальным сообщениям вы обнаружите, что скорость отклика программы снижается. Сборщик мусора занимает больше времени, а приложение выделяет меньше времени на выполнение.
Размер кучи не должен превышать 80% доступной физической памяти.Обычно для параметров -Xms и -Xmx должны быть установлены одинаковые значения, а -Xmn составляет 1/4 значения -Xmx.
Параметры размера кучи -Xms -Xmn не должны превышать размер физической памяти. В противном случае появится сообщение «Ошибка при инициализации виртуальной машины. Не удалось зарезервировать достаточно места для кучи объектов».
==========================================================
После ночи напряженной работы я наконец завершил программу замены файлов для указанной строки, но поскольку я хочу заменить слишком много файлов html для общесайтовой программы, поэтому затмение всегда заканчивается в каталоге После сообщения об исключении java.lang.OutOfMemoryError: пространство кучи Java произошел сбой.
Я подумал, что слишком поздно перерабатывать из-за частых операций, поэтому я добавил Thread.sleep (1000) после каждого цикла и обнаружил, что он умрет в этом каталоге, поэтому я изменил 1000 на 5000 или умер там. Я думаю, что это может быть не так просто перерабатывать, возможно, JVM Sun просто не выпускает для этой ситуации.
Затем я добавил -Xmx256M к параметру запуска, на этот раз все было нормально.
Подумав об этом, я до сих пор мало что знаю о принципах сборки мусора, я проверил это в Интернете и нашел несколько хороших статей.
http://java.ccidnet.com/art/3539/20060314/476073_1.html
http://www.pconline.com.cn/pcedu/empolder/gj/java/0509/701281.html
Также существуют: Управление кучей Java – сборка мусора. Следует отметить следующие моменты, которые могут использоваться в качестве рекомендаций при написании программ:
(1) Не пытайтесь предполагать время, когда происходит сборка мусора, причем все это неизвестно. Например, временный объект в методе становится бесполезным после вызова метода, и его память может быть освобождена в это время.
(2) Java предоставляет несколько классов, которые занимаются сборкой мусора, и предоставляет способ принудительного вызова функции сборки мусора System.gc (), но это также ненадежный метод. Java не гарантирует, что сборка мусора будет запускаться каждый раз при вызове этого метода. Она просто отправляет такой запрос в JVM. Неизвестно, выполняется ли сборка мусора на самом деле.
(3) Выберите подходящий вам сборщик мусора. Вообще говоря, если система не предъявляет особых требований к производительности, вы можете использовать параметры JVM по умолчанию. В противном случае вы можете рассмотреть возможность использования целевых сборщиков мусора.Например, инкрементные сборщики больше подходят для систем с высокими требованиями к работе в реальном времени. Система имеет более высокую конфигурацию и больше простаивающих ресурсов, вы можете рассмотреть возможность использования параллельного сборщика меток / разверток.
(4) Ключевая и сложная проблема – это утечки памяти. Хорошие навыки программирования и строгое отношение к программированию всегда являются самыми важными. Не позволяйте небольшой собственной ошибке вызвать большую дыру в памяти.
(5) Освободите ссылки на бесполезные объекты как можно скорее.
Когда большинство программистов используют временные переменные, они автоматически устанавливают для ссылочной переменной значение null после выхода из активной области (области), что означает, что сборщик мусора будет собирать объект. Вы должны обратить внимание на то, отслеживается ли объект, на который указывает ссылка, если да, удалите прослушиватель, а затем назначьте нулевое значение.
Другими словами, лучше контролировать операции частого обращения к памяти и освобождения памяти самостоятельно, но метод System.gc () может быть неприменим. Лучше использовать finalize для принудительного выполнения или написать свой собственный метод finalize.
================================================
tomcat
Я обнаружил ошибку TOMCAT: java.lang.OutOfMemoryError: пространство кучи Java, поэтому я проверил информацию и нашел решение:
If Java runs out of memory, the following error occurs:
Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
Java heap size can be increased as follows:
java -Xms -Xmx
Defaults are:
java -Xms32m -Xmx128m
Если вы используете выигрыш
/tomcat/bin/catalina.bat плюс следующая команда:
set JAVA_OPTS=-Xms32m -Xmx256m
Если вы используете unix / linux
/tomcat/bin/catalina.sh плюс следующая команда:
JAVA_OPTS=”-Xms32m -Xmx256m”
инструмент просмотра и анализа памяти jvm
В отрасли существует множество мощных инструментов для профилей Java, таких как Jporfiler и yourkit. Я не хочу говорить об этих платных вещах. Я хочу сказать, что сама java обеспечивает большой мониторинг памяти. Маленькие инструменты, перечисленные ниже инструменты – лишь небольшая часть. Все еще довольно интересно внимательно изучить инструменты jdk 🙂
1: вывод журнала gc
Добавьте -XX: + PrintGC -XX: + PrintGCDetails -XX: + PrintGCTimestamps -XX: + PrintGCApplicationStopedTime к параметрам запуска jvm, jvm выведет сводную информацию gc, подробную информацию, информацию о времени gc и приложения, вызванные gc, в порядке этих параметров. Время паузы. Если вы добавите параметр -Xloggc: путь к файлу после параметра прямо сейчас, информация gc будет выводиться в указанный файл. Другие параметры включают
-verbose: gc и -XX: + PrintTenuringDistribution и т. д.
2：jconsole
jconsole - это инструмент анализа памяти, который поставляется с jdk, который предоставляет графический интерфейс. Вы можете просматривать информацию о памяти, информацию о потоках, информацию о загрузке классов и информацию о MBean отслеживаемом jvm.
jconsole находится в каталоге bin в каталоге jdk. Это jconsole.exe в Windows и jconsole.sh в Unix и Linux. jconsole может контролировать локальные приложения и удаленные приложения. Чтобы отслеживать локальные приложения, выполните jconsole pid, pid - это идентификатор запущенного java-процесса, если вы не укажете параметр pid, после выполнения команды jconsole вы увидите всплывающее диалоговое окно, локальный java-процесс указан выше, вы можете выбрать один Для мониторинга. Если вы хотите контролировать удаленно, вы должны добавить что-то в параметр jvm удаленного сервера, потому что удаленный мониторинг jconsole основан на jmx. Подробнее об использовании jconsole см. В статье, посвященной jconsle. Я также подробно расскажу о jconsole в блоге. .
3:jviusalvm
После обновления JDK6 7 jdk запустил еще один инструмент: jvisualvm, виртуальную машину визуализации java, которая не только предоставляет функции, аналогичные jconsole, но также обеспечивает диагностику памяти jvm и процессора в реальном времени, а также ручной дамп памяти jvm и ручное выполнение. gc.
Как и jconsole, запустите jviusalvm, выполните jviusalvm в каталоге bin jdk, jviusalvm.exe под Windows, jviusalvm.sh под linux и unix.
4：jmap
jmap - это инструмент анализа памяти jvm, который поставляется с jdk и находится в каталоге bin jdk. Использование команды jmap в jdk1.6:
Код коллекции HTML-кода
Usage:
jmap -histo (to connect to running process and print histogram of java object heap
jmap -dump: (to connect to running process and dump java heap)
dump-options: format=b binary default file=
dump heap to
Example: jmap -dump:format=b,file=heap.bin
jmap -histo <pid> отображает на экране состояние памяти jvm указанного pid. Возьмем, к примеру, мой компьютер, выполните эту команду, на экране отобразится:
Код коллекции HTML-кода
1: 24206 2791864 < constMethodKlass >
2: 22371 2145216 [C
3: 24206 1940648 < methodKlass >
4: 1951 1364496 < constantPoolKlass >
5: 26543 1282560 < symbolKlass >
6: 6377 1081744 [B
7: 1793 909688 < constantPoolCacheKlass >
8: 1471 614624 < instanceKlassKlass >
9: 14581 548336 [Ljava.lang.Object;
10: 3863 513640 [I
11: 20677 496248 java.lang.String
12: 3621 312776 [Ljava.util.HashMap
E
n
t
r
y
;
13
:
3335266800
j
a
v
a
.
l
a
n
g
.
r
e
f
l
e
c
t
.
M
e
t
h
o
d
14
:
8256264192
j
a
v
a
.
i
o
.
O
b
j
e
c
t
S
t
r
e
a
m
C
l
a
s
s
Entry; 13: 3335 266800 java.lang.reflect.Method 14: 8256 264192 java.io.ObjectStreamClass
WeakClassKey
15: 7066 226112 java.util.TreeMap
E
n
t
r
y
16
:
2355173304
[
S
17
:
1687161952
j
a
v
a
.
l
a
n
g
.
C
l
a
s
s
18
:
2769150112
[
[
I
19
:
3563142520
j
a
v
a
.
u
t
i
l
.
H
a
s
h
M
a
p
20
:
5562133488
j
a
v
a
.
u
t
i
l
.
H
a
s
h
M
a
p
Entry 16: 2355 173304 [S 17: 1687 161952 java.lang.Class 18: 2769 150112 [[I 19: 3563 142520 java.util.HashMap 20: 5562 133488 java.util.HashMap
Entry
Total 239019 17140408
Чтобы облегчить просмотр, я удалил несколько строк. Из приведенной выше информации легко увидеть, что #instance относится к количеству объектов, #bytes относится к объему памяти, занимаемой этими объектами, а имя класса относится к типу объекта.
Снова посмотрите на параметр dump jmap: он выводит информацию о памяти кучи jvm в файл и выполняет его на моей машине.
jmap -dump:file=c:dump.txt 340
Обратите внимание, что 340 – это pid java-процесса моей машины. Размер выгруженного файла превышает 10 мегабайт, и я только что открыл tomcat и запустил очень простое приложение без какого-либо доступа. Его можно представить на большом и загруженном сервере. , Насколько большим должен быть файл дампа? Что вам нужно знать, так это то, что информация о файле дампа очень примитивна и определенно не подходит для просмотра людьми напрямую, а содержимое, отображаемое jmap -histo, слишком простое, например, оно только показывает, сколько памяти занимают определенные типы объектов и количество этих объектов. , Но нет более подробной информации, например, кто создал эти объекты. Итак, какая польза от файла дампа? Конечно полезно, потому что есть инструмент для анализа файла дампа памяти jvm.
5：jhat
Как упоминалось выше, существует множество инструментов, которые могут анализировать файл дампа памяти jvm, jhat - это инструмент, который поставляется с sun jdk6 и выше, расположен в каталоге bin jdk, выполнить jhat -J -Xmx512m [file], file - это путь к файлу дампа. В jhat встроен простой веб-сервер. После выполнения этой команды jhat отображает адрес доступа к результату анализа в командной строке. Вы можете использовать параметр -port, чтобы указать порт. Для конкретного использования вы можете выполнить jhat -heap для просмотра справочной информации. После доступа по указанному адресу вы можете увидеть информацию, отображаемую на странице, которая намного богаче и детальнее, чем команда jmap -histo.
6: анализатор памяти eclipse
Вышеупомянутый jhat, он может анализировать файл дампа jvm, но это все текстовое отображение, анализатор памяти eclipse, это подключаемый модуль, предоставляемый eclipse для анализа дампа кучи jvm, веб-сайт http://www.eclipse.org/mat, Скорость его анализа выше, чем у jhat, а результат анализа отображается в графическом интерфейсе, который более читабелен, чем jhat. Фактически, jvisualvm также может анализировать файлы дампа, которые также отображаются в графическом интерфейсе.
7：jstat
Если jmap имеет тенденцию анализировать информацию об объекте в памяти jvm, то jsta стремится анализировать ситуацию gc с памятью jvm. Оба являются инструментами анализа памяти JVM, но, очевидно, они анализируются с разных сторон. Существует множество часто используемых параметров jsat, таких как -gc, -gcutil, -gccause. Конкретные функции этих параметров можно просмотреть в справочной информации jsat. Я часто использую -gcutil. Функция этого параметра постоянно отображает информацию о сборке мусора в текущей указанной памяти jvm. .
На этом компьютере я выполняю jstat -gcutil 340 10000. Эта команда выводит информацию gc jvm каждые 10 секунд. 10000 обозначает интервал в 10000 миллисекунд. На экране отображается следующая информация (я взял только первую строку, потому что она отображается с определенной частотой, поэтому при фактическом исполнении строк будет много):
S0 S1 E O P YGC YGCT FGC FGCT GCT
54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763
количество. . . Как это сказать, чтобы понять, что означает эта информация, вы также должны иметь определенное представление о механизме gc в jvm. На самом деле, если вы знаете gc jvm горячей точки солнца, вам будет легко понять эту информацию, но люди, не знакомые с механизмом gc, немного необъяснимы, поэтому здесь я сначала расскажу о механизме gc jvm солнца. Говоря о gc, на самом деле, это не просто концепция java. Фактически, до java во многих языках была концепция gc. GC означает сборку мусора. Это скорее алгоритмическая вещь, но с определенными языками. Это не имеет большого значения, поэтому об истории gc я не буду говорить о мейнстримовом алгоритме gc. Это слишком далеко, и это ерунда. Текущая JVM Sun, модель управления памятью - это модель поколений, поэтому, конечно, сборщик мусора собирается поколениями. Что означают поколения? Он состоит в том, чтобы разделить объект на три уровня в соответствии с жизненным циклом, а именно: новое поколение, старое поколение и постоянное поколение. Когда объекты распределяются впервые, большинство из них находятся в кайнозое. Когда запускается представление кайнозойского GC, GC в кайнозойском диапазоне выполняется один раз. Это называется второстепенным GC. Если второстепенный GC выполняется несколько раз, объекты все еще остаются. Выжить, передать эти объекты старому поколению, потому что эти объекты проверены организацией. Частота gc старого поколения будет ниже. Если старое поколение выполняет gc, это полный gc, потому что это не частичный gc, а gc во всем диапазоне памяти. Это приведет к приостановке приложения, потому что полный сбор памяти должен быть заблокирован Память, никакие новые объекты не могут быть выделены в память.Постоянная генерация - это некоторые объекты, которые не исчезнут в течение периода JVM, такие как определение класса, информация области метода JVM, например статические блоки. Главное, что новое поколение разделено на три пространства: eden, susvivor0 и susvivor1. В буквальном понимании это Eden Park, Survival Zone 1 и Survival Zone 2. Новые объекты размещаются в области eden. Когда область eden заполнена, используется алгоритм mark-copy, то есть выжившие объекты в области eden извлекаются, и эти объекты копируются в s0 или s1, а затем область eden очищается. Gc jvm не так уж прост. Например, есть последовательный сбор, параллельный сбор, параллельный сбор и знаменитый алгоритм поезда, но это слишком далеко, чтобы говорить, хорошо иметь общее представление об этом сейчас. Сказав это, давайте посмотрим на вывод информации выше:
S0 S1 E O P YGC YGCT FGC FGCT GCT
54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763
S0: Зона susvivor0 нового поколения, коэффициент использования площадей 54 … 62%
S1: область susvivor1 нового поколения, коэффициент использования пространства составляет 0,00% (поскольку второй второстепенный сбор не был выполнен)
E: район Эдем, коэффициент использования площадей – 42,87%
О: Старое поколение, коэффициент использования площадей 43,52%
P: постоянный ремень, коэффициент использования пространства 86,24%
YGC: Незначительное время выполнения gc 1792 раза
YGCT: незначительное время gc затрачено 5,093 миллисекунды
FGC: полное выполнение gc раз 33
FGCT: полный gc занимает 7,670 миллисекунд
GCT: общее время, затрачиваемое gc, составляет 12,763 миллисекунды.
Исходный адрес:https://www.cnblogs.com/bolang100/p/6478537.html
If you keep on allocating & keeping references to object, you will fill up any amount of memory you have.
One option is to do a transparent file close & open when they switch tabs (you only keep a pointer to the file, and when the user switches tab, you close & clean all the objects… it’ll make the file change slower… but…), and maybe keep only 3 or 4 files on memory.
Other thing you should do is, when the user opens a file, load it, and intercept any OutOfMemoryError, then (as it is not possible to open the file) close that file, clean its objects and warn the user that he should close unused files.
Your idea of dynamically extending virtual memory doesn’t solve the issue, for the machine is limited on resources, so you should be carefull & handle memory issues (or at least, be carefull with them).
A couple of hints i’ve seen with memory leaks is:
–> Keep on mind that if you put something into a collection and afterwards forget about it, you still have a strong reference to it, so nullify the collection, clean it or do something with it… if not you will find a memory leak difficult to find.
–> Maybe, using collections with weak references (weakhashmap…) can help with memory issues, but you must be carefull with it, for you might find that the object you look for has been collected.
–> Another idea i’ve found is to develope a persistent collection that stored on database objects least used and transparently loaded. This would probably be the best approach…
How to solve java.lang.outofmemoryerror: java heap space or exception in thread “main”? Know reasons caused by and how to solve it guide.
Introduction
In Java JVM allocates a defined memory size for storing objects created during program execution known as Java Heap Space. Along with it, JVM allocates another memory called PermGen space: permanent generation space.
Java Heap Space
However, we can change the default size with the JVM options.
Most importantly, Oracle completely removed this memory space in the JDK 8 release.
Memory space in the JDK 8 release
Understanding OutOfMemoryError in Java
There most common reason for this error is simple –
If we try to fit a large application into a smaller space. In other words, the application just requires more Java heap space than available to it to operate normally.
Other causes:
- Spikes in usage/data volume- The application was designed to handle a certain amount of users or a certain amount of data. When the number of users or the volume of data suddenly spikes and crosses the expected limit. The operation which functioned normally before the spike ceases to operate and triggers the OutOfMemoryError.
- Memory leaks- A particular type of programming error will lead your application to constantly consume more memory. Every time the leaking functionality of the application is used it leaves some objects behind in the Java heap space. Over time the leaked objects consume all of the available heap space and trigger the already familiar OutOfMemoryError.
Exception in thread “main” java.lang.outofmemoryerror: java heap space
Exception in thread "main" java.lang.OutOfMemoryErrorWhat is causing it?
Generally, bad programming results in OutOfMemoryError. OutOfMemoryError usually means that we’re doing something wrong, either holding onto objects too long or trying to process too much data at a time. Sometimes, it indicates a problem that’s out of our control, such as a third-party library that caches strings, or an application server that doesn’t clean up after deploys.
GC Overhead limit exceeded- This error indicates that the garbage collector is running all the time and the Java program is making very slow progress. If such an event occurs then an OutOfMemoryError is thrown.
Stack vs Java Heap Space
Heap Space
Whenever we create an object, it’s always created in the Heap space.
Stack Memory
Java Stack memory is used for the execution of a thread. It also contains method references.
Note: String Pool is also a part of Java Heap Memory.
Solving java.lang.outofmemoryerror: java heap space error
Increase Java Heap size in Java
The default size of Heap space in Java is 128MB on most of 32 bit Sun’s JVM but it highly varies from JVM to JVM.
For instance, the default maximum and start heap size for the 32-bit Solaris Operating System (SPARC Platform Edition) is -Xms=3670K and -Xmx=64M. And default values of heap size parameters on 64-bit systems have been increased up by approximately 30%.
Also, if we are using a throughput garbage collector in Java 1.5 default maximum heap size of JVM would be Physical Memory/4, and the default initial heap size would be Physical Memory/16.
Another way to find the default heap size of JVM is to start an application with default heap parameters and monitor using JConsole. It is available on JDK 1.5 onwards, on the VMSummary tab, you will be able to see the maximum heap size.
Moreover, we can increase the size of java heap space based on our application need and it is always recommended to avoid using default JVM heap values. Therefore, if our application is large and lots of objects are created. We can change the size of heap space by using JVM options -Xms and -Xmx. Here, Xms denotes the starting size of Heap while -Xmx denotes the maximum size of Heap in Java.
There is another parameter called -Xmn. It denotes the size of the new generation of Java Heap Space. The only thing is we can’t change the size of Heap in Java dynamically. We can only provide the Java Heap Size parameter while starting JVM.
Conclusion
We hope you got your error resolved. Let us know by commenting if you need any help or have any questions.
If this article helped you feel free to share. Keep reading and sharing. Kudos!!
Я в общем склеил всю музыку, которую хотел сделать фоновой, и вышло 315мб. Закинул в проект, и попытался с помощью запустить. Но не вышло( Код метода для проигрывания музыки:
public static void play(URL url)
{
clip = AudioSystem.getClip();
clip.open(AudioSystem.getAudioInputStream(url));
clip.start();
}
Как это исправить? Пробовал увлеичить память, но мне ошибку выбивало, то ли памяти мало, то ли ещё что-то. Всего на компе 2гб ОЗУ.
задан 21 июн 2016 в 14:16
Попробуйте увеличить размер хипа для jvm.
Для этого в аргументах jvm укажите:
java -Xmx1024m -Xms256m
Параметр Xmx указывает максимальный размер занимаемый хипом, а Xms — начальный размер выделенный под хип.
Если используете IntelliJ Idea, то сделать это можно так: выбираете конфигурацию запуска и в поле VM Options прописываете данную строчку (-Xmx1024m -Xms256m без java).
В Eclipse: Run -> Run configuration -> вкладка arguments -> VM arguments
ответ дан 21 июн 2016 в 14:21
cadmycadmy
1,9056 золотых знаков25 серебряных знаков48 бронзовых знаков
5
Как я понел у вас музыка хранится в оперативке. П.с никто не хранит музыку в оперативке, там всегда были буферы размером(сколько указано в формате вашего файла, например битрейт в 128 кб). Я думаю вам не получится реализовать это с помощью Clip, или занесите вашу музыку в файл чтоли.
ответ дан 22 июн 2016 в 13:10
Denis KotlyarovDenis Kotlyarov
2,8563 золотых знака25 серебряных знаков53 бронзовых знака
7
