So i bought a new laptop today (Asus TUF Gaming FX505DD) so not a cheap one. I installed minecraft and played it for a while. then i installed mods. one of the mods needed a later version of forge. so i installed it. Take note that my minecraft works without mods with both Reccomended (by forge) AND required (by Ichunutil) versions. When i load up minecraft with the required version, i get this error: The game crashed whilst registering texture
Error: java.lang.OutOfMemoryError: Java heap space.
Ive looked around a bit on the internet. Looked for some solutions but nothing seems to help. So i hope someone on here can help me. This is the full crash report:
—- Minecraft Crash Report ——— Minecraft Crash Report —-
WARNING: coremods are present: OpenModsCorePlugin (OpenModsLib-1.12.2.jar) CXLibraryCore (cxlibrary-1.12.1-1.6.1.jar) LoadingPlugin (Quark-Mod-1.12.2.jar)Contact their authors BEFORE contacting forge
// Hey, that tickles! Hehehe!
Time: 9/18/19 12:45 AMDescription: Registering texture
java.lang.OutOfMemoryError: Java heap space at java.awt.image.BufferedImage.getRGB(BufferedImage.java:961) at net.minecraft.client.renderer.texture.TextureUtil.func_110993_a(TextureUtil.java:248) at net.minecraft.client.renderer.texture.TextureUtil.func_110995_a(TextureUtil.java:230) at net.minecraft.client.renderer.texture.TextureUtil.func_110989_a(TextureUtil.java:198) at net.minecraft.client.renderer.texture.SimpleTexture.func_110551_a(SourceFile:46) at net.minecraft.client.renderer.texture.TextureManager.func_110579_a(TextureManager.java:69) at net.minecraft.client.renderer.texture.TextureManager.func_110577_a(TextureManager.java:44) at net.minecraft.client.renderer.RenderGlobal.<init>(RenderGlobal.java:160) at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:527) at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:378) at net.minecraft.client.main.Main.main(SourceFile:123) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
A detailed walkthrough of the error, its code path and all known details is as follows:—————————————————————————————
— Head —Thread: Client threadStacktrace: at java.awt.image.BufferedImage.getRGB(BufferedImage.java:961) at net.minecraft.client.renderer.texture.TextureUtil.func_110993_a(TextureUtil.java:248) at net.minecraft.client.renderer.texture.TextureUtil.func_110995_a(TextureUtil.java:230) at net.minecraft.client.renderer.texture.TextureUtil.func_110989_a(TextureUtil.java:198) at net.minecraft.client.renderer.texture.SimpleTexture.func_110551_a(SourceFile:46)
— Resource location being registered —Details: Resource location: minecraft:textures/misc/forcefield.png Texture object class: net.minecraft.client.renderer.texture.SimpleTextureStacktrace: at net.minecraft.client.renderer.texture.TextureManager.func_110579_a(TextureManager.java:69) at net.minecraft.client.renderer.texture.TextureManager.func_110577_a(TextureManager.java:44) at net.minecraft.client.renderer.RenderGlobal.<init>(RenderGlobal.java:160) at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:527)
— Initialization —Details:Stacktrace: at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:378) at net.minecraft.client.main.Main.main(SourceFile:123) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
— System Details —Details: Minecraft Version: 1.12.2 Operating System: Windows 10 (amd64) version 10.0 Java Version: 1.8.0_51, Oracle Corporation Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation Memory: 61494392 bytes (58 MB) / 536870912 bytes (512 MB) up to 536870912 bytes (512 MB) JVM Flags: 9 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx2G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M -Xmx512M IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0 FML: MCP 9.42 Powered by Forge 14.23.5.2781 28 mods loaded, 28 mods active States: ‘U’ = Unloaded ‘L’ = Loaded ‘C’ = Constructed ‘H’ = Pre-initialized ‘I’ = Initialized ‘J’ = Post-initialized ‘A’ = Available ‘D’ = Disabled ‘E’ = Errored
| State | ID | Version | Source | Signature | |:—— |:—————— |:—————— |:——————————————— |:—————————————- | | LCH | minecraft | 1.12.2 | minecraft.jar | None | | LCH | mcp | 9.42 | minecraft.jar | None | | LCH | FML | 8.0.99.99 | forge-1.12.2-14.23.5.2781.jar | e3c3d50c7c986df74c645c0ac54639741c90a557 | | LCH | forge | 14.23.5.2781 | forge-1.12.2-14.23.5.2781.jar | e3c3d50c7c986df74c645c0ac54639741c90a557 | | LCH | openmodscore | 0.12.2 | minecraft.jar | None | | LCH | armourers_workshop | 1.12.2-0.49.1 | Armourers-Workshop-1.12.2-0.49.1.jar | None | | LCH | quark | r1.5-130 | Quark-Mod-1.12.2.jar | None | | LCH | autoreglib | 1.3-20 | AutoRegLib-1.12.2.jar | None | | LCH | bibliocraft | 2.4.5 | BiblioCraft-Mod-1.12.2.jar | None | | LCH | codechickenlib | 3.2.3.357 | CodeChickenLib-1.12.2-3.2.3.357-universal.jar | f1850c39b2516232a2108a7bd84d1cb5df93b261 | | LCH | chickenchunks | 2.4.2.74 | ChickenChunks-1.12.2-2.4.2.74-universal.jar | f1850c39b2516232a2108a7bd84d1cb5df93b261 | | LCH | sanlib | 1.5.1 | SanLib-1.12.2-1.5.1.jar | df48348748b5e141b1d118e2302a8d5be930b708 | | LCH | claysoldiers | 3.0.0-beta.2 | ClaySoldiersMod-1.12.2-3.0.0-beta.2.jar | None | | LCH | cxlibrary | 1.6.1 | cxlibrary-1.12.1-1.6.1.jar | None | | LCH | disenchanter | 1.6 | disenchanter-[1.12]1.6.jar | None | | LCH | improvedbackpacks | 1.12.2-1.3.0.0 | ImprovedBackpacks-1.12.2-1.3.0.0.jar | None | | LCH | ironchest | 1.12.2-7.0.67.844 | Iron-Chests-Mod-1.12.2.jar | None | | LCH | morefurnaces | 1.10.5 | MoreFurnaces-1.12.2-1.10.6.jar | None | | LCH | cfm | 6.3.1 | MrCrayfishs-Furniture-Mod-1.12.2.jar | None | | LCH | openmods | 0.12.2 | OpenModsLib-1.12.2.jar | d2a9a8e8440196e26a268d1f3ddc01b2e9c572a5 | | LCH | openblocks | 1.8.1 | OpenBlocks-Mod-1.12.2.jar | d2a9a8e8440196e26a268d1f3ddc01b2e9c572a5 | | LCH | roguelike | 1.8.0 | Roguelike-Dungeons-Mod-1.12.2.jar | None | | LCH | sanplayermodel | 1.1.1 | SanLib-1.12.2-1.5.1.jar | None | | LCH | smarthoppers | 4.1.5 | smarthoppers-mc1.12.2-4.1.5.jar | None | | LCH | speedyhoppers | 1.1.19 | speedyhoppers-1.1.19.jar | None | | LCH | uncraftingtable | 1.8-beta6 | Uncrafting-Table-Mod-1.12.2.jar | None | | LCH | worldedit | 6.1.8 | worldedit-forge-mc1.12-6.1.8-dist.jar | None | | LCH | xlfoodmod | 1.12.2-1.9.2 | XL-Food-Mod-1.12.2-1.9.2.jar | None |
Loaded coremods (and transformers): OpenModsCorePlugin (OpenModsLib-1.12.2.jar) openmods.core.OpenModsClassTransformerCXLibraryCore (cxlibrary-1.12.1-1.6.1.jar) cubex2.cxlibrary.CoreModTransformerLoadingPlugin (Quark-Mod-1.12.2.jar) vazkii.quark.base.asm.ClassTransformer GL info: ‘ Vendor: ‘ATI Technologies Inc.’ Version: ‘4.5.13541 Compatibility Profile Context 25.20.14150.1’ Renderer: ‘AMD Radeon(TM) Vega 8 Graphics’ OpenModsLib class transformers: [llama_null_fix:FINISHED],[horse_base_null_fix:FINISHED],[pre_world_render_hook:FINISHED],[player_render_hook:FINISHED],[horse_null_fix:FINISHED] Launched Version: 1.12.2-forge1.12.2-14.23.5.2781 LWJGL: 2.9.4 OpenGL: AMD Radeon(TM) Vega 8 Graphics GL version 4.5.13541 Compatibility Profile Context 25.20.14150.1, ATI Technologies Inc. GL Caps: Using GL 1.3 multitexturing.Using GL 1.3 texture combiners.Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported.Shaders are available because OpenGL 2.1 is supported.VBOs are available because OpenGL 1.5 is supported.
Using VBOs: Yes Is Modded: Definitely; Client brand changed to ‘fml,forge’ Type: Client (map_client.txt) Resource Packs: Current Language: English (US) Profiler Position: N/A (disabled) CPU: 8x AMD Ryzen 5 3550H with Radeon Vega Mobile Gfx
Если вы словили OutOfMemoryError, то это вовсе не значит, что ваше приложение создает много объектов, которые не могут почиститься сборщиком мусора и заполняют всю память, выделенную вами с помощью параметра -Xmx. Я, как минимум, могу придумать два других случая, когда вы можете увидеть эту ошибку. Дело в том, что память java процесса не ограничивается областью -Xmx, где ваше приложение программно создает объекты.
Область памяти, занимаемая java процессом, состоит из нескольких частей. Тип OutOfMemoryError зависит от того, в какой из них не хватило места.
1. java.lang.OutOfMemoryError: Java heap space
Не хватает место в куче, а именно, в области памяти в которую помещаются объекты, создаваемые программно в вашем приложении. Размер задается параметрами -Xms и -Xmx. Если вы пытаетесь создать объект, а места в куче не осталось, то получаете эту ошибку. Обычно проблема кроется в утечке памяти, коих бывает великое множество, и интернет просто пестрит статьями на эту тему.
2. java.lang.OutOfMemoryError: PermGen space
Данная ошибка возникает при нехватке места в Permanent области, размер которой задается параметрами -XX:PermSize и -XX:MaxPermSize. Что там лежит и как бороться с OutOfMemoryError возникающей там, я уже описал подробнейшим образом тут.
3. java.lang.OutOfMemoryError: GC overhead limit exceeded
Данная ошибка может возникнуть как при переполнении первой, так и второй областей. Связана она с тем, что памяти осталось мало и GC постоянно работает, пытаясь высвободить немного места. Данную ошибку можно отключить с помощью параметра -XX:-UseGCOverheadLimit, но, конечно же, её надо не отключать, а либо решать проблему утечки памяти, либо выделять больше объема, либо менять настройки GC.
4. java.lang.OutOfMemoryError: unable to create new native thread
Впервые я столкнулся с данной ошибкой несколько лет назад, когда занимался нагрузочным тестированием и пытался выяснить максимальное количество пользователей, которые могут работать с нашим веб-приложением. Я использовал специальную тулзу, которая позволяла логинить пользователей и эмулировать их стандартные действия. На определенном количестве клиентов, я начал получать OutOfMemoryError. Не особо вчитываясь в текст сообщения и думая, что мне не хватает памяти на создание сессии пользователя и других необходимых объектов, я увеличил размер кучи приложения (-Xmx). Каково же было мое удивление, когда после этого количество пользователей одновременно работающих с системой только уменьшилось. Давайте подробно разберемся как же такое получилось.
На самом деле это очень просто воспроизвести на windows на 32-битной машине, так как там процессу выделяется не больше 2Гб.
Допустим у вас есть приложение с большим количеством одновременно работающих пользователей, которое запускается с параметрами -Xmx1024M -XX:MaxPermSize=256M -Xss512K. Если всего процессу доступно 2G, то остается свободным еще коло 768M. Именно в данном остатке памяти и создаются стеки потоков. Таким образом, примерно вы можете создать не больше 768*(1024/512)=1536 (у меня при таких параметрах получилось создать 1316) нитей (см. рисунок в начале статьи), после чего вы получите OutOfMemoryError. Если вы увеличиваете -Xmx, то количество потоков, которые вы можете создать соответственно уменьшается. Вариант с уменьшением -Xss, для возможности создания большего количества потоков, не всегда выход, так как, возможно, у вас существуют в системе потоки требующие довольно больших стеков. Например, поток инициализации или какие-нибудь фоновые задачи. Но все же выход есть. Оказывается при программном создании потока, можно указать размер стека: Thread(ThreadGroup group, Runnable target, String name,long stackSize). Таким образом вы можете выставить -Xss довольно маленьким, а действия требующие больших стеков, выполнять в отдельных потоках, созданных с помощью упомянутого выше конструктора.
Более подробно, что же лежит в стеке потока, и куда уходит эта память, можно прочитать тут.
Конечно, вам может показаться данная проблема слегка надуманной, так как большинство серверов нынче крутиться на 64-битной архитектуре, но все же считаю данный пример весьма полезным, так как он помогает разобраться из каких частей состоит память java-процесса.
Какие бывают типы OutOfMemoryError или из каких частей состоит память java процесса
Если вы словили OutOfMemoryError, то это вовсе не значит, что ваше приложение создает много объектов, которые не могут почиститься сборщиком мусора и заполняют всю память, выделенную вами с помощью параметра -Xmx. Я, как минимум, могу придумать два других случая, когда вы можете увидеть эту ошибку. Дело в том, что память java процесса не ограничивается областью -Xmx, где ваше приложение программно создает объекты.
Область памяти, занимаемая java процессом, состоит из нескольких частей. Тип OutOfMemoryError зависит от того, в какой из них не хватило места.
1. java.lang.OutOfMemoryError: Java heap space
Не хватает место в куче, а именно, в области памяти в которую помещаются объекты, создаваемые программно в вашем приложении. Размер задается параметрами -Xms и -Xmx. Если вы пытаетесь создать объект, а места в куче не осталось, то получаете эту ошибку. Обычно проблема кроется в утечке памяти, коих бывает великое множество, и интернет просто пестрит статьями на эту тему.
2. java.lang.OutOfMemoryError: PermGen space
Данная ошибка возникает при нехватке места в Permanent области, размер которой задается параметрами -XX:PermSize и -XX:MaxPermSize. Что там лежит и как бороться с OutOfMemoryError возникающей там, я уже описал подробнейшим образом тут.
3. java.lang.OutOfMemoryError: GC overhead limit exceeded
Данная ошибка может возникнуть как при переполнении первой, так и второй областей. Связана она с тем, что памяти осталось мало и GC постоянно работает, пытаясь высвободить немного места. Данную ошибку можно отключить с помощью параметра -XX:-UseGCOverheadLimit, но, конечно же, её надо не отключать, а либо решать проблему утечки памяти, либо выделять больше объема, либо менять настройки GC.
4. java.lang.OutOfMemoryError: unable to create new native thread
Впервые я столкнулся с данной ошибкой несколько лет назад, когда занимался нагрузочным тестированием и пытался выяснить максимальное количество пользователей, которые могут работать с нашим веб-приложением. Я использовал специальную тулзу, которая позволяла логинить пользователей и эмулировать их стандартные действия. На определенном количестве клиентов, я начал получать OutOfMemoryError. Не особо вчитываясь в текст сообщения и думая, что мне не хватает памяти на создание сессии пользователя и других необходимых объектов, я увеличил размер кучи приложения (-Xmx). Каково же было мое удивление, когда после этого количество пользователей одновременно работающих с системой только уменьшилось. Давайте подробно разберемся как же такое получилось.
На самом деле это очень просто воспроизвести на windows на 32-битной машине, так как там процессу выделяется не больше 2Гб.
Допустим у вас есть приложение с большим количеством одновременно работающих пользователей, которое запускается с параметрами -Xmx1024M -XX:MaxPermSize=256M -Xss512K. Если всего процессу доступно 2G, то остается свободным еще коло 768M. Именно в данном остатке памяти и создаются стеки потоков. Таким образом, примерно вы можете создать не больше 768*(1024/512)=1536 (у меня при таких параметрах получилось создать 1316) нитей (см. рисунок в начале статьи), после чего вы получите OutOfMemoryError. Если вы увеличиваете -Xmx, то количество потоков, которые вы можете создать соответственно уменьшается. Вариант с уменьшением -Xss, для возможности создания большего количества потоков, не всегда выход, так как, возможно, у вас существуют в системе потоки требующие довольно больших стеков. Например, поток инициализации или какие-нибудь фоновые задачи. Но все же выход есть. Оказывается при программном создании потока, можно указать размер стека: Thread(ThreadGroup group, Runnable target, String name,long stackSize). Таким образом вы можете выставить -Xss довольно маленьким, а действия требующие больших стеков, выполнять в отдельных потоках, созданных с помощью упомянутого выше конструктора.
Более подробно, что же лежит в стеке потока, и куда уходит эта память, можно прочитать тут.
Конечно, вам может показаться данная проблема слегка надуманной, так как большинство серверов нынче крутиться на 64-битной архитектуре, но все же считаю данный пример весьма полезным, так как он помогает разобраться из каких частей состоит память java-процесса.
3.2 Understand the OutOfMemoryError Exception
One common indication of a memory leak is the java.lang.OutOfMemoryError exception. Usually, this error is thrown when there is insufficient space to allocate an object in the Java heap. In this case, The garbage collector cannot make space available to accommodate a new object, and the heap cannot be expanded further. Also, this error may be thrown when there is insufficient native memory to support the loading of a Java class. In a rare instance, a java.lang.OutOfMemoryError may be thrown when an excessive amount of time is being spent doing garbage collection and little memory is being freed.
When a java.lang.OutOfMemoryError exception is thrown, a stack trace is also printed.
The java.lang.OutOfMemoryError exception can also be thrown by native library code when a native allocation cannot be satisfied (for example, if swap space is low).
An early step to diagnose an OutOfMemoryError exception is to determine the cause of the exception. Was it thrown because the Java heap is full, or because the native heap is full? To help you find the cause, the text of the exception includes a detail message at the end, as shown in the following exceptions.
In other cases, and in particular for a long-lived application, the message might be an indication that the application is unintentionally holding references to objects, and this prevents the objects from being garbage collected. This is the Java language equivalent of a memory leak. Note: The APIs that are called by an application could also be unintentionally holding object references.
One other potential source of this error arises with 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. Instead, after garbage collection, the objects are queued for finalization, which occurs at a later time. In the Oracle Sun implementation, finalizers are executed by a daemon thread that services the finalization queue. 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. One scenario that can cause this situation is when an application creates high-priority threads that cause the finalization queue to increase at a rate that is faster than the rate at which the finalizer thread is servicing that queue.
If this type of the OutOfMemoryError exception is thrown, you might need to use troubleshooting utilities on the operating system to diagnose the issue further. For more information about tools available for various operating systems, see Native Operating System Tools.
CompressedClassSpaceSize of 4294967296 is invalid; must be between 1048576 and 3221225472.
Note: There is more than one kind of class metadata — klass metadata and other metadata. Only klass metadata is stored in the space bounded by CompressedClassSpaceSize . The other metadata is stored in Metaspace .
Русские Блоги
Итак, обычно есть две причины этой аномалии:
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’ перед /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 к параметру запуска, на этот раз все было нормально.
Подумав об этом, я до сих пор мало что знаю о принципах сборки мусора, я проверил это в Интернете и нашел несколько хороших статей.
Также существуют: Управление кучей Java — сборка мусора. Следует отметить следующие моменты, которые могут использоваться в качестве рекомендаций при написании программ:
(1) Не пытайтесь предполагать время, когда происходит сборка мусора, причем все это неизвестно. Например, временный объект в методе становится бесполезным после вызова метода, и его память может быть освобождена в это время.
(2) Java предоставляет несколько классов, которые занимаются сборкой мусора, и предоставляет способ принудительного вызова функции сборки мусора System.gc (), но это также ненадежный метод. Java не гарантирует, что сборка мусора будет запускаться каждый раз при вызове этого метода. Она просто отправляет такой запрос в JVM. Неизвестно, выполняется ли сборка мусора на самом деле.
(3) Выберите подходящий вам сборщик мусора. Вообще говоря, если система не предъявляет особых требований к производительности, вы можете использовать параметры JVM по умолчанию. В противном случае вы можете рассмотреть возможность использования целевых сборщиков мусора.Например, инкрементные сборщики больше подходят для систем с высокими требованиями к работе в реальном времени. Система имеет более высокую конфигурацию и больше простаивающих ресурсов, вы можете рассмотреть возможность использования параллельного сборщика меток / разверток.
(4) Ключевая и сложная проблема — это утечки памяти. Хорошие навыки программирования и строгое отношение к программированию всегда являются самыми важными. Не позволяйте небольшой собственной ошибке вызвать большую дыру в памяти.
(5) Освободите ссылки на бесполезные объекты как можно скорее.
Когда большинство программистов используют временные переменные, они автоматически устанавливают для ссылочной переменной значение null после выхода из активной области (области), что означает, что сборщик мусора будет собирать объект. Вы должны обратить внимание на то, отслеживается ли объект, на который указывает ссылка, если да, удалите прослушиватель, а затем назначьте нулевое значение.
Другими словами, лучше контролировать операции частого обращения к памяти и освобождения памяти самостоятельно, но метод System.gc () может быть неприменим. Лучше использовать finalize для принудительного выполнения или написать свой собственный метод finalize.
Я обнаружил ошибку 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
-verbose: gc и -XX: + PrintTenuringDistribution и т. д.
Код коллекции 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 -dump:file=c:dump.txt 340
Обратите внимание, что 340 — это pid java-процесса моей машины. Размер выгруженного файла превышает 10 мегабайт, и я только что открыл tomcat и запустил очень простое приложение без какого-либо доступа. Его можно представить на большом и загруженном сервере. , Насколько большим должен быть файл дампа? Что вам нужно знать, так это то, что информация о файле дампа очень примитивна и определенно не подходит для просмотра людьми напрямую, а содержимое, отображаемое jmap -histo, слишком простое, например, оно только показывает, сколько памяти занимают определенные типы объектов и количество этих объектов. , Но нет более подробной информации, например, кто создал эти объекты. Итак, какая польза от файла дампа? Конечно полезно, потому что есть инструмент для анализа файла дампа памяти jvm.
6: анализатор памяти eclipse
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 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% (поскольку второй второстепенный сбор не был выполнен)
I only have a few mods. I don’t know why this is happening.
Error Message-
The game crashed whilst registering texture
Error: java.lang.OutOfMemoryError: Java heap space
Crash Report-
—- Minecraft Crash Report —-
WARNING: coremods are present:
LoadingPlugin (Quark-r1.4-122.jar)
Contact their authors BEFORE contacting forge
// Ooh. Shiny.
Time: 2/1/18 10:53 PM
Description: Registering texture
java.lang.OutOfMemoryError: Java heap space
at java.awt.image.BufferedImage.getRGB(BufferedImage.java:961)
at net.minecraft.client.renderer.texture.TextureUtil.func_110993_a(TextureUtil.java:248)
at net.minecraft.client.renderer.texture.TextureUtil.func_110995_a(TextureUtil.java:230)
at net.minecraft.client.renderer.texture.TextureUtil.func_110989_a(TextureUtil.java:198)
at net.minecraft.client.renderer.texture.SimpleTexture.func_110551_a(SourceFile:46)
at net.minecraft.client.renderer.texture.TextureManager.func_110579_a(TextureManager.java:69)
at net.minecraft.client.renderer.texture.TextureManager.func_110577_a(TextureManager.java:44)
at net.minecraftforge.client.CloudRenderer.reloadTextures(CloudRenderer.java:474)
at net.minecraftforge.client.CloudRenderer.func_110549_a(CloudRenderer.java:483)
at net.minecraft.client.resources.SimpleReloadableResourceManager.func_110542_a(SimpleReloadableResourceManager.java:121)
at net.minecraftforge.client.CloudRenderer.<init>(CloudRenderer.java:78)
at net.minecraftforge.fml.client.FMLClientHandler.getCloudRenderer(FMLClientHandler.java:1126)
at net.minecraftforge.fml.client.FMLClientHandler.updateCloudSettings(FMLClientHandler.java:1132)
at net.minecraftforge.common.ForgeInternalHandler.checkSettings(ForgeInternalHandler.java:97)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_15_ForgeInternalHandler_checkSettings_ClientTickEvent.invoke(.dynamic)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:179)
at net.minecraftforge.fml.common.FMLCommonHandler.onPostClientTick(FMLCommonHandler.java:348)
at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1909)
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:1096)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:397)
at net.minecraft.client.main.Main.main(SourceFile:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
A detailed walkthrough of the error, its code path and all known details is as follows:
—————————————————————————————
— Head —
Thread: Client thread
Stacktrace:
at java.awt.image.BufferedImage.getRGB(BufferedImage.java:961)
at net.minecraft.client.renderer.texture.TextureUtil.func_110993_a(TextureUtil.java:248)
at net.minecraft.client.renderer.texture.TextureUtil.func_110995_a(TextureUtil.java:230)
at net.minecraft.client.renderer.texture.TextureUtil.func_110989_a(TextureUtil.java:198)
at net.minecraft.client.renderer.texture.SimpleTexture.func_110551_a(SourceFile:46)
— Resource location being registered —
Details:
Resource location: minecraft:textures/environment/clouds.png
Texture object class: net.minecraft.client.renderer.texture.SimpleTexture
Stacktrace:
at net.minecraft.client.renderer.texture.TextureManager.func_110579_a(TextureManager.java:69)
at net.minecraft.client.renderer.texture.TextureManager.func_110577_a(TextureManager.java:44)
at net.minecraftforge.client.CloudRenderer.reloadTextures(CloudRenderer.java:474)
at net.minecraftforge.client.CloudRenderer.func_110549_a(CloudRenderer.java:483)
at net.minecraft.client.resources.SimpleReloadableResourceManager.func_110542_a(SimpleReloadableResourceManager.java:121)
at net.minecraftforge.client.CloudRenderer.<init>(CloudRenderer.java:78)
at net.minecraftforge.fml.client.FMLClientHandler.getCloudRenderer(FMLClientHandler.java:1126)
at net.minecraftforge.fml.client.FMLClientHandler.updateCloudSettings(FMLClientHandler.java:1132)
at net.minecraftforge.common.ForgeInternalHandler.checkSettings(ForgeInternalHandler.java:97)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_15_ForgeInternalHandler_checkSettings_ClientTickEvent.invoke(.dynamic)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:179)
at net.minecraftforge.fml.common.FMLCommonHandler.onPostClientTick(FMLCommonHandler.java:348)
at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1909)
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:1096)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:397)
at net.minecraft.client.main.Main.main(SourceFile:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
— System Details —
Details:
Minecraft Version: 1.12.2
Operating System: Windows 10 (amd64) version 10.0
Java Version: 1.8.0_25, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 65564280 bytes (62 MB) / 1073741824 bytes (1024 MB) up to 1073741824 bytes (1024 MB)
JVM Flags: 8 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx1G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=16M
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
FML: MCP 9.42 Powered by Forge 14.23.1.2608 21 mods loaded, 21 mods active
States: ‘U’ = Unloaded ‘L’ = Loaded ‘C’ = Constructed ‘H’ = Pre-initialized ‘I’ = Initialized ‘J’ = Post-initialized ‘A’ = Available ‘D’ = Disabled ‘E’ = Errored
| State | ID | Version | Source | Signature |
|:—— |:—————— |:—————— |:——————————————— |:—————————————- |
| UCHIJA | minecraft | 1.12.2 | minecraft.jar | None |
| UCHIJA | mcp | 9.42 | minecraft.jar | None |
| UCHIJA | FML | 8.0.99.99 | forge-1.12.2-14.23.1.2608.jar | e3c3d50c7c986df74c645c0ac54639741c90a557 |
| UCHIJA | forge | 14.23.1.2608 | forge-1.12.2-14.23.1.2608.jar | e3c3d50c7c986df74c645c0ac54639741c90a557 |
| UCHIJA | mercurius_updater | 1.0 | MercuriusUpdater-1.12.2.jar | None |
| UCHIJA | advancedcombat | 1.1.2 | advancedcombat-1.1.2-[1.12].jar | None |
| UCHIJA | biomesoplenty | 7.0.1.2297 | BiomesOPlenty-1.12.2-7.0.1.2297-universal.jar | None |
| UCHIJA | craftstudioapi | 1.0.0 | CraftStudio-1.0.0.93-mc1.12-alpha.jar | None |
| UCHIJA | quark | r1.4-122 | Quark-r1.4-122.jar | None |
| UCHIJA | animania | 1.4.4 | animania-1.12.2-1.4.4.jar | None |
| UCHIJA | autoreglib | 1.3-15 | AutoRegLib-1.3-15.jar | None |
| UCHIJA | ptrmodellib | 1.0.0 | Decocraft-2.5.2_1.12.2.jar | None |
| UCHIJA | props | 2.5.2 | Decocraft-2.5.2_1.12.2.jar | None |
| UCHIJA | foamflower | 1.12-0.0.1.0 | foamflower-1.12-0.0.1.0.jar | None |
| UCHIJA | ichunutil | 7.1.4 | iChunUtil-1.12.2-7.1.4.jar | None |
| UCHIJA | hats | 7.0.0 | Hats-1.12.2-7.0.2.jar | None |
| UCHIJA | inventorypets | 1.4.9.9b | inventorypets-1.12-1.4.9.9b.jar | None |
| UCHIJA | jei | 4.8.5.147 | jei_1.12.2-4.8.5.147.jar | None |
| UCHIJA | harvestcraft | 1.12.2m | Pam’s+HarvestCraft+1.12.2m.jar | None |
| UCHIJA | vending | 1.12.2-3.0.1.0-rc1 | vending-1.12.2-3.0.1.0-rc1.jar | None |
| UCHIJA | xaerominimap | 1.14.5 | Xaeros_Minimap_1.14.5_Forge_1.12.jar | None |
Loaded coremods (and transformers):
LoadingPlugin (Quark-r1.4-122.jar)
vazkii.quark.base.asm.ClassTransformer
GL info: ‘ Vendor: ‘Intel’ Version: ‘3.1.0 — Build 9.17.10.4459’ Renderer: ‘Intel(R) HD Graphics 2000’
Launched Version: 1.12.2-forge1.12.2-14.23.1.2608
LWJGL: 2.9.4
OpenGL: Intel(R) HD Graphics 2000 GL version 3.1.0 — Build 9.17.10.4459, Intel
GL Caps: Using GL 1.3 multitexturing.
Using GL 1.3 texture combiners.
Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported.
Shaders are available because OpenGL 2.1 is supported.
VBOs are available because OpenGL 1.5 is supported.
Using VBOs: Yes
Is Modded: Definitely; Client brand changed to ‘fml,forge’
Type: Client (map_client.txt)
Resource Packs:
Current Language: English (US)
Profiler Position: N/A (disabled)
CPU: 4x Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
error log:
—- Minecraft Crash Report —- // There are four lights!
Time: 28-7-19 1:54 Description: Initializing game
java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:3332) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:137) at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:121) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:569) at java.lang.StringBuffer.append(StringBuffer.java:369) at java.io.BufferedReader.readLine(BufferedReader.java:370) at java.io.BufferedReader.readLine(BufferedReader.java:389) at org.apache.commons.io.IOUtils.readLines(IOUtils.java:1294) at org.apache.commons.io.IOUtils.readLines(IOUtils.java:1248) at org.apache.commons.io.IOUtils.readLines(IOUtils.java:1229) at cvs.a(SourceFile:237) at cvs.<init>(SourceFile:210) at cvo.au(SourceFile:441) at cvo.b(SourceFile:395) at net.minecraft.client.main.Main.main(SourceFile:154)
A detailed walkthrough of the error, its code path and all known details is as follows:
— Head — Thread: Client thread Stacktrace: at java.util.Arrays.copyOf(Arrays.java:3332) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:137) at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:121) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:569) at java.lang.StringBuffer.append(StringBuffer.java:369) at java.io.BufferedReader.readLine(BufferedReader.java:370) at java.io.BufferedReader.readLine(BufferedReader.java:389) at org.apache.commons.io.IOUtils.readLines(IOUtils.java:1294) at org.apache.commons.io.IOUtils.readLines(IOUtils.java:1248) at org.apache.commons.io.IOUtils.readLines(IOUtils.java:1229) at cvs.a(SourceFile:237) at cvs.<init>(SourceFile:210) at cvo.au(SourceFile:441)
— Initialization — Details: Stacktrace: at cvo.b(SourceFile:395) at net.minecraft.client.main.Main.main(SourceFile:154)
— System Details — Details: Minecraft Version: 1.14.3 Operating System: Windows 7 (amd64) version 6.1 Java Version: 1.8.0_51, Oracle Corporation Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation Memory: 944121680 bytes (900 MB) / 2147483648 bytes (2048 MB) up to 2147483648 bytes (2048 MB) JVM Flags: 9 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xss1M -Xmx2G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=1G Launched Version: 1.14.3 LWJGL: 3.2.2 build 10 OpenGL: NO CONTEXT GL Caps: Using VBOs: Yes Is Modded: Probably not. Jar signature remains and client brand is untouched. Type: Client (map_client.txt) Resource Packs: ERROR NullPointerException: null Current Language: ERROR NullPointerException: null CPU: <unknown>
В 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
Я пишу на стороне клиента качели приложение (графический конструктор шрифтов) на Java 5. Недавно я столкнулся с java.lang.OutOfMemoryError: Java heap space ошибка, потому что я не консервативен в использовании памяти. Пользователь может открывать неограниченное количество файлов, и программа сохраняет открытые объекты в памяти. После быстрого исследования я нашел эргономика в виртуальной машине 5.0 Java и другие говорят на машине Windows, что JVM по умолчанию максимальный размер кучи как 64MB.
учитывая эту ситуацию, как я должен бороться с этим ограничением?
я мог бы увеличить максимальный размер кучи используя командная строка опция java, но для этого потребуется выяснить доступную ОЗУ и написать некоторую программу запуска или скрипт. Кроме того, увеличение до некоторого конечного максимума в конечном итоге не избавляет от проблемы.
я мог бы переписать часть моего кода, чтобы часто сохранять объекты в файловой системе (используя базу данных то же самое), чтобы освободить память. Это может сработать, но это, вероятно, тоже много работы.
Если бы вы могли указать мне на детали вышеуказанных идей или некоторые альтернативы, такие как автоматическая виртуальная память, динамически расширяя размер кучи, это будет здорово.
18 ответов
в конечном счете у вас всегда есть конечный максимум кучи, чтобы использовать независимо от того, на какой платформе вы работаете. В Windows 32 бит это около 2 Гб (не конкретно куча, но общий объем памяти на процесс). Просто случается, что Java решает сделать значение по умолчанию меньше (предположительно, чтобы программист не мог создавать программы с неуправляемым распределением памяти, не сталкиваясь с этой проблемой и не изучая точно, что они делают).
Так это учитывая, что есть несколько подходов, которые вы можете предпринять, чтобы определить, какой объем памяти вам нужен, или уменьшить объем используемой памяти. Одной из распространенных ошибок в языках сбора мусора, таких как Java или C#, является сохранение ссылок на объекты, которые вы больше не используете, или выделение многих объектов, когда вы можете использовать их вместо этого. Пока объекты имеют ссылку на них, они будут продолжать использовать пространство кучи, поскольку сборщик мусора не удалит их.
в этом случае вы можно использовать профилировщик памяти Java, чтобы определить, какие методы в вашей программе выделяют большое количество объектов, а затем определить, есть ли способ убедиться, что они больше не ссылаются или не выделяют их в первую очередь. Один вариант, который я использовал в прошлом «СПМ» http://www.khelekore.org/jmp/.
Если вы определяете, что вы выделяете эти объекты по какой-то причине, и вам нужно сохранить ссылки (в зависимости от того, что вы делаете это возможно, это так), вам просто нужно будет увеличить максимальный размер кучи при запуске программы. Однако, как только вы сделаете профилирование памяти и поймете, как выделяются ваши объекты, вы должны иметь лучшее представление о том, сколько памяти вам нужно.
В общем, если вы не можете гарантировать, что ваша программа будет работать в некотором конечном объеме памяти (возможно, в зависимости от размера ввода), вы всегда столкнетесь с этой проблемой. Только после исчерпания всего этого вам нужно будет посмотреть в кэширование объектов на диск и т. д. На данный момент у вас должна быть очень веская причина сказать: «Мне нужен Xgb памяти» для чего-то, и вы не можете обойти это, улучшив свои алгоритмы или шаблоны выделения памяти. Как правило, это происходит только в случае алгоритмов, работающих с большими наборами данных (например, с базой данных или какой-либо программой научного анализа), а затем становятся полезными такие методы, как кэширование и сопоставление памяти.
запустите Java с параметром командной строки -Xmx, который устанавливает максимум размер кучи.
Подробнее см. здесь..
вы можете указать для каждого проекта, сколько места кучи ваш проект хочет
вслед за Затмение Гелиос/Юнона/Кеплер:
Правой Кнопкой Мыши на
Run As - Run Configuration - Arguments - Vm Arguments,
затем добавить этот
-Xmx2048m
увеличение размера кучи не является «исправлением», это» штукатурка», 100% временная. Он снова во что-то еще. Чтобы избежать этих проблем, напишите высокопроизводительный код.
- использовать локальные переменные везде, где это возможно.
- убедитесь, что вы выбрали правильный объект (например, выбор между string, StringBuffer и StringBuilder)
- используйте хорошую систему кода для вашей программы (например: использование статических переменных против нестатических переменных)
- прочее что может сработать с вашим кодом.
- попробуйте двигаться с Multy THREADING
30
автор: Yohan Weerasinghe
большая оговорка — — — — в моем офисе мы обнаружили, что (на некоторых машинах windows) мы не могли выделить более 512m для кучи Java. Это оказалось связано с антивирусным продуктом Kaspersky, установленным на некоторых из этих машин. После удаления этого AV-продукта мы обнаружили, что можем выделить по крайней мере 1.6 gb, i.e, — Xmx1600m (M обязательно, иначе это приведет к другой ошибке «слишком маленькая начальная куча») работает.
нет идеи, если это происходит с другими продуктами AV, но предположительно, это происходит потому, что AV-программа резервирует небольшой блок памяти в каждом адресном пространстве, тем самым предотвращая одно действительно большое выделение.
аргумент VM работал для меня в eclipse. Если вы используете eclipse версии 3.4, выполните следующие действия
на Run --> Run Configurations --> выберите проект под сборка —> перейдите на вкладку «версии» —> введите -Xmx1024m.
в качестве альтернативы вы могли бы сделать Run --> Run Configurations --> select the "JRE" tab --> введите —Xmx1024m
это должно увеличить кучу памяти для всех сборок / проектов. Выше размер памяти составляет 1 ГБ. Вы можете оптимизировать так, как хотите.
да, с -Xmx вы можете настроить больше памяти для вас JVM.
Чтобы быть уверенным, что вы не утечете или не потеряете память. Возьмите дамп кучи и используйте анализатор памяти Eclipse для анализа потребления памяти.
Я хотел бы добавить рекомендации от oracle устранение неисправностей статьи
исключение в потоке thread_name:java.ленг.OutOfMemoryError: пространство кучи Java
подробное сообщение пространство кучи Java указывает, что объект не может быть выделен в куче Java. Эта ошибка не обязательно подразумевает утечку памяти
возможные причины:
-
простой проблема конфигурации, где указанный размер кучи недостаточен для приложения.
-
приложение непреднамеренно содержит ссылки на объекты, и это предотвращает объекты от сбора мусора.
-
чрезмерное использование финализаторов.
еще один потенциальный источник этой ошибки возникает с приложениями, которые чрезмерно используют метод завершения. Если класс имеет метод finalize, то объекты этого типа не имеют своего пространства, освобожденного во время сборки мусора
после вывоз мусора, объекты в очереди для завершение, который происходит в более позднее время. финализаторы выполняются потоком демона, который обслуживает очередь завершения. Если финализатор поток не может идти в ногу с очередью завершения, а затем кучей Java может заполнить и этот тип OutOfMemoryError исключение быть брошенным.
один сценарий, который может вызвать эту ситуацию, когда приложение создает высокоприоритетные темы причиной завершение очередь для увеличения со скоростью, которая быстрее, чем скорость, с которой поток финализатора обслуживает эту очередь.
выполните следующие действия:
-
открыть catalina.sh из tomcat / bin.
-
изменить JAVA_OPTS к
JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms1536m -Xmx1536m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+DisableExplicitGC" -
перезапустите tomcat
Я читал где — то еще, что вы можете попробовать-поймать java.ленг.OutOfMemoryError и в блоке catch вы можете освободить все ресурсы, которые, как вы знаете, могут использовать много памяти, закрыть соединения и т. д., а затем сделать систему.gc () затем повторите попытку, что бы вы ни собирались сделать.
другой способ-это хотя, я не знаю, будет ли это работать, но в настоящее время я тестирую, будет ли он работать на моем приложении.
идея состоит в том, чтобы сделать сборку мусора путем вызова Система.gc (), который, как известно, увеличивает свободную память. Вы можете продолжать проверять это после выполнения кода поглощения памяти.
//Mimimum acceptable free memory you think your app needs
long minRunningMemory = (1024*1024);
Runtime runtime = Runtime.getRuntime();
if(runtime.freeMemory()<minRunningMemory)
System.gc();
Я столкнулся с той же проблемой размера кучи java.
У меня есть два решения, если вы используете Java 5(1.5).
1st: — просто установите jdk1.6 и перейдите в настройки eclipse и установите путь JRE jav1 1.6, как вы установили.
2nd: — проверьте свой аргумент VM и пусть это будет то, что есть.
просто добавьте одну строку ниже всех аргументов, присутствующих в аргументах VM, как
— Xms512m-Xmx512m-XX: MaxPermSize=…м (192 м).
Я думаю, что это будет работать…
6
автор: Soumya Sandeep Mohanty
простой способ решить OutOfMemoryError в java, чтобы увеличить максимальный размер кучи с помощью параметров JVM -Xmx512M, это немедленно решит ваш OutOfMemoryError. Это мое предпочтительное решение, когда я получаю OutOfMemoryError в Eclipse, Maven или ANT при создании проекта, потому что на основе размера проекта вы можете легко исчерпать память.
вот пример увеличения максимального размера кучи JVM, также лучше сохранить-Xmx в-xms рацион либо 1: 1, либо 1: 1.5, если вы устанавливаете размер кучи в приложении java.
export JVM_ARGS="-Xms1024m -Xmx1024m"
Ссылка
Если вам нужно контролировать использование памяти во время выполнения, java.ленг.пакет управления предлагает MBeans, которые можно использовать для мониторинга пулов памяти в вашей виртуальной машине (например, eden space, tenured generation и т. д.), а также поведения сборки мусора.
свободное пространство кучи, сообщаемое этими MBeans, будет сильно отличаться в зависимости от поведения GC, особенно если ваше приложение генерирует много объектов, которые позже GC-ed. Одним из возможных подходов является мониторинг свободного пространства кучи после каждый полный-GC, который вы можете использовать для принятия решения об освобождении памяти путем сохранения объектов.
в конечном счете, лучше всего ограничить сохранение памяти, насколько это возможно, в то время как производительность остается приемлемой. Как отмечалось в предыдущем комментарии, память всегда ограничена, но ваше приложение должно иметь стратегию борьбы с истощением памяти.
обратите внимание, что если вам это нужно в ситуации развертывания, рассмотрите использование Java WebStart (с версией «ondisk», а не сетевой — возможно в Java 6u10 и более поздних версиях), поскольку это позволяет указать различные аргументы JVM кросс-платформенным способом.
в противном случае вам понадобится конкретная операционная система запуска, которая устанавливает необходимые аргументы.
3
автор: Thorbjørn Ravn Andersen
по умолчанию для разработки JVM использует малый размер и небольшую конфигурацию для других функций, связанных с производительностью. Но для производства вы можете настроить, например (кроме того, может существовать определенная конфигурация сервера приложений) — > (Если все еще недостаточно памяти для удовлетворения запроса, и куча уже достигла максимального размера, произойдет OutOfMemoryError)
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-XX:ParallelGCThreads=8
-XX:+CMSClassUnloadingEnabled
-XX:InitiatingHeapOccupancyPercent=70
-XX:+UnlockDiagnosticVMOptions
-XX:+UseConcMarkSweepGC
-Xms512m
-Xmx8192m
-XX:MaxPermSize=256m (in java 8 optional)
например: на платформе linux для производственного режима предпочтительны настройки.
после загрузки и настройка сервера таким образом http://www.ehowstuff.com/how-to-install-and-setup-apache-tomcat-8-on-centos-7-1-rhel-7/
1.создать setenv.sh файл в папке / opt/tomcat/bin/
touch /opt/tomcat/bin/setenv.sh
2.Откройте и напишите этот параметр для настройки предпочтительного режима.
nano /opt/tomcat/bin/setenv.sh
export CATALINA_OPTS="$CATALINA_OPTS -XX:ParallelGCThreads=8"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+CMSClassUnloadingEnabled"
export CATALINA_OPTS="$CATALINA_OPTS -XX:InitiatingHeapOccupancyPercent=70"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+UnlockDiagnosticVMOptions"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+UseConcMarkSweepGC"
export CATALINA_OPTS="$CATALINA_OPTS -Xms512m"
export CATALINA_OPTS="$CATALINA_OPTS -Xmx8192m"
export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxMetaspaceSize=256M"
3.service tomcat restart
обратите внимание, что JVM использует больше памяти, чем просто кучи. Например
Методы Java, стеки потоков и собственные дескрипторы выделяются в память
отдельно от кучи, а также внутренних структур данных JVM.
Если вы продолжаете выделять и сохранять ссылки на объект, вы заполните любое количество памяти, которое у вас есть.
один из вариантов — сделать прозрачный файл close & open при переключении вкладок (вы только держите указатель на файл, а когда пользователь переключает вкладку, вы закрываете и очищаете все объекты… это замедлит изменение файла… но…), и, возможно, сохранить только 3 или 4 файла в памяти.
другое, что вы должны сделать, это, когда пользователь открывает файл, загрузить его и перехватите любой OutOfMemoryError, затем (поскольку открыть файл невозможно) закройте этот файл, очистите его объекты и предупредите пользователя, что он должен закрыть неиспользуемые файлы.
ваша идея динамического расширения виртуальной памяти не решает проблему, поскольку машина ограничена ресурсами, поэтому вы должны быть осторожны и обрабатывать проблемы с памятью (или, по крайней мере, быть осторожными с ними).
несколько подсказок, которые я видел с утечками памяти:
—> имейте в виду, что если вы поместите что-то в коллекцию, а затем забудьте об этом, у вас все еще есть сильная ссылка на нее, поэтому аннулируйте коллекцию, очистите ее или сделайте что-то с ней… если нет, вы обнаружите, что утечку памяти трудно найти.
—> возможно, используя коллекции со слабыми ссылками (weakhashmap…) может помочь с проблемами памяти, но вы должны будьте осторожны с ним, потому что вы можете обнаружить, что объект, который вы ищете, был собран.
—> еще одна идея, которую я найдено для разработки постоянной коллекции, которая хранится на объектах базы данных, наименее используемых и прозрачно загруженных. Это, вероятно, было бы лучшим подходом…
Что касается netbeans, вы можете установить максимальный размер кучи для решения проблемы. Во-первых, перейдите в «Выполнить», затем- > «настройка конфигурации проекта» — > «настройка» — > «запуск» его всплывающего окна — > «опция VM» — > заполните «- Xms2048m-Xmx2048m».
Если эта проблема возникает в Wildfly 8 и JDK1.8, затем нам нужно указать настройки MaxMetaSpace вместо настроек PermGen.
например, нам нужно добавить следующую конфигурацию в setenv.sh файл wildfly.
JAVA_OPTS="$JAVA_OPTS -XX:MaxMetaspaceSize=256M"
для получения дополнительной информации, пожалуйста, проверьте Проблема С Кучей Wildfly
В Java все объекты хранятся в куче. Они выделяются с помощью оператора new. Исключение OutOfMemoryError в Java выглядит так:
Исключение в потоке "main" java.lang.OutOfMemoryError: пространство кучи Java
Обычно эта ошибка возникает, когда виртуальная машина Java не может выделить объект, потому что ему не хватает памяти, и сборщик мусора не может сделать больше памяти.
OutOfMemoryError обычно означает, что вы делаете что-то неправильно, либо слишком долго удерживаете объекты, либо пытаетесь обработать слишком много данных за раз. Иногда это указывает на проблему, которая находится вне вашего контроля, например на стороннюю библиотеку, которая кэширует строки, или сервер приложений, который не очищается после развертывания. А иногда это не имеет ничего общего с объектами в куче.
Исключение java.lang.OutOfMemoryError также может быть вызвано кодом собственной библиотеки, когда не может быть выполнено собственное выделение (например, если пространство подкачки мало). Давайте разберемся в различных случаях, когда может возникнуть ошибка OutOfMemory.
Симптом или основная причина?
To find the cause, the text of the exception includes a detailed message at the end. Lets examine all the errors.
- Error 1 – Java heap space : This error arises due to the 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. Instead, after garbage collection, the objects are queued for finalization, which occurs at a later time. Implementation:
- finalizers are executed by a daemon thread that services the finalization queue.
- 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.
- The problem can also be as simple as a configuration issue, where the specified heap size (or the default size, if it is not specified) is insufficient for the application.
importjava.util.*;publicclassHeap {staticList<String> list =newArrayList<String>();publicstaticvoidmain(String args[])throwsException{Integer[] array =newInteger[10000*10000];}}When you execute the above code above you might expect it to run forever without any problems. 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.
Prevention : Check how to monitor objects for which finalization is pending in Monitor the Objects Pending Finalization.
- Error 2 – GC Overhead limit exceeded : This error indicates that the garbage collector is running all the time and Java program is making very slow progress. After a garbage collection, if the Java process is spending more than approximately 98% of its time doing garbage collection and if it is recovering less than 2% of the heap and has been doing so far the last 5 (compile time constant) consecutive garbage collections, then a java.lang.OutOfMemoryError is thrown.
This exception is typically thrown because the amount of live data barely fits into the Java heap having little free space for new allocations.importjava.util.*;publicclassWrapper {publicstaticvoidmain(String args[])throwsException{Map m =newHashMap();m = System.getProperties();Random r =newRandom();while(true) {m.put(r.nextInt(),"randomValue");}}}If you’ll run this program with java -Xmx100m -XX:+UseParallelGC Wrapper then the output will be something like this :
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded at java.lang.Integer.valueOf(Integer.java:832) at Wrapper.main(error.java:9)Prevention : Increase the heap size and turn off it with the command line flag -XX:-UseGCOverheadLimit.
- Error 3 – Permgen space is thrown : Java memory is separated into different regions. The size of all those regions, including the permgen area, is set during the JVM launch. If you do not set the sizes yourself, platform-specific defaults will be used.
The java.lang.OutOfMemoryError: PermGen space error indicates that the Permanent Generation’s area in memory is exhausted.importjavassist.ClassPool;publicclassPermgen {staticClassPool classPool = ClassPool.getDefault();publicstaticvoidmain(String args[])throwsException{for(inti =0; i <1000000000; i++) {Class c = classPool.makeClass(com.saket.demo.Permgen" + i).toClass();System.out.println(c.getName());}}}In the above sample code, code iterates over a loop and generates classes at run time. Class generation complexity is being taken care of by the Javassist library.
Running the above code will keep generating new classes and loading their definitions into Permgen space until the space is fully utilized and the java.lang.OutOfMemoryError: Permgen space is thrown.
Prevention : When the OutOfMemoryError due to PermGen exhaustion is caused during the application launch, the solution is simple. The application just needs more room to load all the classes to the PermGen area so we just need to increase its size. To do so, alter your application launch configuration and add (or increase if present) the -XX:MaxPermSize parameter similar to the following example:java -XX:MaxPermSize=512m com.saket.demo.Permgen
- Error 4 – Metaspace : Java class metadata is allocated in native memory. If metaspace for class metadata is exhausted, a java.lang.OutOfMemoryError exception with a detail MetaSpace is thrown.
The amount of metaspace that can be used for class metadata is limited by the parameter MaxMetaSpaceSize, which is specified on the command line. When the amount of native memory needed for a class metadata exceeds MaxMetaSpaceSize, a java.lang.OutOfMemoryError exception with a detail MetaSpace is thrown.importjava.util.*;publicclassMetaspace {staticjavassist.ClassPool cp = javassist.ClassPool.getDefault();publicstaticvoidmain(String args[])throwsException{for(inti =0; i <100000; i++) {Class c = cp.makeClass("com.saket.demo.Metaspace"+ i).toClass();}}}This code will keep generating new classes and loading their definitions to Metaspace until the space is fully utilized and the java.lang.OutOfMemoryError: Metaspace is thrown. When launched with -XX:MaxMetaspaceSize=64m then on Mac OS X my Java 1.8.0_05 dies at around 70, 000 classes loaded.
Prevention : If MaxMetaSpaceSize, has been set on the command-line, increase its value. MetaSpace is allocated from the same address spaces as the Java heap. Reducing the size of the Java heap will make more space available for MetaSpace. This is only a correct trade-off if there is an excess of free space in the Java heap.
- Error 5 – Requested array size exceeds VM limit : This error indicates that the application attempted to allocate an array that is larger than the heap size. For example, if an application attempts to allocate an array of 1024 MB but the maximum heap size is 512 MB then OutOfMemoryError will be thrown with “Requested array size exceeds VM limit”.
importjava.util.*;publicclassGFG {staticList<String> list =newArrayList<String>();publicstaticvoidmain(String args[])throwsException{Integer[] array =newInteger[10000*10000];}}The java.lang.OutOfMemoryError: Requested array size exceeds VM limit can appear as a result of either of the following situations:
- Your arrays grow too big and end up having a size between the platform limit and the Integer.MAX_INT
- You deliberately try to allocate arrays larger than 2^31-1 elements to experiment with the limits.
- Error 6 – Request size bytes for reason. Out of swap space? : This apparent exception occurs when an allocation from the native heap failed and the native heap might be close to exhaustion. The error indicates the size (in bytes) of the request that failed and the reason for the memory request. Usually the reason is the name of the source module reporting the allocation failure, although sometimes it is the actual reason.
java.lang.OutOfMemoryError: Out of swap space error is often caused by operating system level issues, such as:- The operating system is configured with insufficient swap space.
- Another process on the system is consuming all memory resources.
Prevention : When this error message is thrown, the VM invokes the fatal error handling mechanism (that is, it generates a fatal error log file, which contains useful information about the thread, process, and system at the time of the crash). In the case of native heap exhaustion, the heap memory and memory map information in the log can be useful
- Error 7 : reason stack_trace_with_native_method : Whenever this error message(reason stack_trace_with_native_method) is thrown then a stack trace is printed in which the top frame is a native method, then this is an indication that a native method has encountered an allocation failure. The difference between this and the previous message is that the allocation failure was detected in a Java Native Interface (JNI) or native method rather than in the JVM code.
importjava.util.*;publicclassGFG {publicstaticvoidmain(String args[])throwsException{while(true) {newThread(newRunnable(){publicvoidrun(){try{Thread.sleep(1000000000);}catch(InterruptedException e){}}}).start();}}}The exact native thread limit is platform-dependent, for example tests Mac OS X reveal that:
64-bit Mac OS X 10.9, Java 1.7.0_45 – JVM dies after #2031 threads have been created
Prevention : Use native utilities of the OS to further diagnose the issue. For more information about tools available for various operating systems, see Native Operating System tools.
Reference :
https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html
This article is contributed by Saket Kumar. If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above.
Attention reader! Don’t stop learning now. Get hold of all the important Java Foundation and Collections concepts with the Fundamentals of Java and Java Collections Course at a student-friendly price and become industry ready. To complete your preparation from learning a language to DS Algo and many more, please refer Complete Interview Preparation Course.
The game crashed whilst mouseclicked event handler
Error: java.lang.OutOfMemoryError: Java heap space
—- Minecraft Crash Report —-
// You should try our sister game, Minceraft!
Time: 27/09/18 20:03
Description: mouseClicked event handler
java.lang.OutOfMemoryError: Java heap space
at ij.e(SourceFile:73)
at cka.c(SourceFile:34)
at cfs.a(SourceFile:1471)
at cnb.i(SourceFile:302)
at cnb.e(SourceFile:223)
at cnb.mouseClicked(SourceFile:169)
at chf.a(SourceFile:21)
at chk.mouseClicked(SourceFile:278)
at chp.mouseClicked(SourceFile:46)
at cfu.b(SourceFile:83)
at cfu$$Lambda$1005/1676424742.run(Unknown Source)
at ckc.a(SourceFile:430)
at cfu.a(SourceFile:83)
at cfu$$Lambda$839/1494382097.invoke(Unknown Source)
at org.lwjgl.glfw.GLFWMouseButtonCallbackI.callback(GLFWMouseButtonCallbackI.java:36)
at org.lwjgl.system.JNI.invokeV(Native Method)
at org.lwjgl.glfw.GLFW.glfwWaitEventsTimeout(GLFW.java:3108)
at cgc.a(SourceFile:321)
at cfs.c(SourceFile:875)
at cfs.a(SourceFile:395)
at net.minecraft.client.main.Main.main(SourceFile:144)
A detailed walkthrough of the error, its code path and all known details is as follows:
—————————————————————————————
— Head —
Thread: Client thread
Stacktrace:
at ij.e(SourceFile:73)
at cka.c(SourceFile:34)
at cfs.a(SourceFile:1471)
at cnb.i(SourceFile:302)
at cnb.e(SourceFile:223)
at cnb.mouseClicked(SourceFile:169)
at chf.a(SourceFile:21)
at chk.mouseClicked(SourceFile:278)
at chp.mouseClicked(SourceFile:46)
at cfu.b(SourceFile:83)
at cfu$$Lambda$1005/1676424742.run(Unknown Source)
— Affected screen —
Details:
Screen name: cna
Stacktrace:
at ckc.a(SourceFile:430)
at cfu.a(SourceFile:83)
at cfu$$Lambda$839/1494382097.invoke(Unknown Source)
at org.lwjgl.glfw.GLFWMouseButtonCallbackI.callback(GLFWMouseButtonCallbackI.java:36)
at org.lwjgl.system.JNI.invokeV(Native Method)
at org.lwjgl.glfw.GLFW.glfwWaitEventsTimeout(GLFW.java:3108)
at cgc.a(SourceFile:321)
at cfs.c(SourceFile:875)
at cfs.a(SourceFile:395)
at net.minecraft.client.main.Main.main(SourceFile:144)
— System Details —
Details:
Minecraft Version: 1.13.1
Operating System: Windows 10 (amd64) version 10.0
Java Version: 1.8.0_51, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 14059376 bytes (13 MB) / 268435456 bytes (256 MB) up to 268435456 bytes (256 MB)
JVM Flags: 10 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xss1M -Xmx1G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=16M -Xmx256M
Launched Version: 1.13.1
LWJGL: 3.1.6 build 14
OpenGL: GeForce GTX 1050 Ti/PCIe/SSE2 GL version 4.6.0 NVIDIA 390.65, NVIDIA Corporation
GL Caps: Using GL 1.3 multitexturing.
Using GL 1.3 texture combiners.
Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported.
Shaders are available because OpenGL 2.1 is supported.
VBOs are available because OpenGL 1.5 is supported.
Using VBOs: Yes
Is Modded: Probably not. Jar signature remains and client brand is untouched.
Type: Client (map_client.txt)
Resource Packs:
Current Language: English (US)
Profiler Position: N/A (disabled)
CPU: 8x Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz_
%MCEPASTEBIN%—- Minecraft Crash Report —-// You should try our sister game, Minceraft!
Time: 27/09/18 20:03Description: mouseClicked event handler
java.lang.OutOfMemoryError: Java heap space at ij.e(SourceFile:73) at cka.c(SourceFile:34) at cfs.a(SourceFile:1471) at cnb.i(SourceFile:302) at cnb.e(SourceFile:223) at cnb.mouseClicked(SourceFile:169) at chf.a(SourceFile:21) at chk.mouseClicked(SourceFile:278) at chp.mouseClicked(SourceFile:46) at cfu.b(SourceFile:83) at cfu$$Lambda$1005/1676424742.run(Unknown Source) at ckc.a(SourceFile:430) at cfu.a(SourceFile:83) at cfu$$Lambda$839/1494382097.invoke(Unknown Source) at org.lwjgl.glfw.GLFWMouseButtonCallbackI.callback(GLFWMouseButtonCallbackI.java:36) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwWaitEventsTimeout(GLFW.java:3108) at cgc.a(SourceFile:321) at cfs.c(SourceFile:875) at cfs.a(SourceFile:395) at net.minecraft.client.main.Main.main(SourceFile:144)
A detailed walkthrough of the error, its code path and all known details is as follows:—————————————————————————————
— Head —Thread: Client threadStacktrace: at ij.e(SourceFile:73) at cka.c(SourceFile:34) at cfs.a(SourceFile:1471) at cnb.i(SourceFile:302) at cnb.e(SourceFile:223) at cnb.mouseClicked(SourceFile:169) at chf.a(SourceFile:21) at chk.mouseClicked(SourceFile:278) at chp.mouseClicked(SourceFile:46) at cfu.b(SourceFile:83) at cfu$$Lambda$1005/1676424742.run(Unknown Source)
— Affected screen —Details: Screen name: cnaStacktrace: at ckc.a(SourceFile:430) at cfu.a(SourceFile:83) at cfu$$Lambda$839/1494382097.invoke(Unknown Source) at org.lwjgl.glfw.GLFWMouseButtonCallbackI.callback(GLFWMouseButtonCallbackI.java:36) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwWaitEventsTimeout(GLFW.java:3108) at cgc.a(SourceFile:321) at cfs.c(SourceFile:875) at cfs.a(SourceFile:395) at net.minecraft.client.main.Main.main(SourceFile:144)
— System Details —Details: Minecraft Version: 1.13.1 Operating System: Windows 10 (amd64) version 10.0 Java Version: 1.8.0_51, Oracle Corporation Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation Memory: 14059376 bytes (13 MB) / 268435456 bytes (256 MB) up to 268435456 bytes (256 MB) JVM Flags: 10 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xss1M -Xmx1G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=16M -Xmx256M Launched Version: 1.13.1 LWJGL: 3.1.6 build 14 OpenGL: GeForce GTX 1050 Ti/PCIe/SSE2 GL version 4.6.0 NVIDIA 390.65, NVIDIA Corporation GL Caps: Using GL 1.3 multitexturing.Using GL 1.3 texture combiners.Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported.Shaders are available because OpenGL 2.1 is supported.VBOs are available because OpenGL 1.5 is supported.
Using VBOs: Yes Is Modded: Probably not. Jar signature remains and client brand is untouched. Type: Client (map_client.txt) Resource Packs: Current Language: English (US) Profiler Position: N/A (disabled) CPU: 8x Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz