What to Do about OutOfMemoryError
One common issue that many developers have to address is that of applications that terminate with java.lang.OutOfMemoryError. That error is thrown when there is insufficient space to allocate an object. That is, garbage collection cannot make any further space available to accommodate a new object, and the heap cannot be further expanded. An OutOfMemoryError does not necessarily imply a memory leak. The issue might simply be a configuration issue, for example if the specified heap size (or the default size if not specified) is insufficient for the application.
The first step in diagnosing an OutOfMemoryError is to examine the full error message. In the exception message, further information is supplied after “java.lang.OutOfMemoryError”. Here are some common examples of what that additional information may be, what it may mean, and what to do about it:
• Java heap space
This indicates that an object could not be allocated in the heap . The issue may be just a configuration problem . You could get this error, for example, if the maximum heap size specified by the –Xmx command line option (or selected by default) is insufficient for the application. It could also be an indication that objects that are no longer needed cannot be garbage collected because the application is unintentionally holding references to them . The HAT tool can be used to view all reachable objects and understand which references are keeping each one alive. One other potential source of this error could be the excessive use of finalizers by the application such that the thread to invoke the finalizers cannot keep up with the rate of addition of finalizers to the queue . The jconsole management tool can be used to monitor the number of objects that are pending finalization.
• PermGen space
This indicates that the permanent generation is full . As described earlier, that is the area of the heap where the JVM stores its metadata. If an application loads a large number of classes, then the permanent generation may need to be increased. You can do so by specifying the command line option –XX:MaxPermSize=n, where n specifies the size.
• Requested array size exceeds VM limit
This indicates that the application attempted to allocate an array that is larger than the heap size. For example, if an application tries to allocate an array of 512MB but the maximum heap size is 256MB,then this error will be thrown. In most cases the problem is likely to be either that the heap size is too small or that a bug results in the application attempting to create an array whose size is calculated to be incorrectly huge.
HotSpot Generations
Memory in the Java HotSpot virtual machine is organized into three generations: a young generation , an old generation(Tenured Gen ), and a permanent generation . Most objects are initially allocated in the young generation. The old generation contains objects that have survived some number of young generation collections, as well as some large objects that may be allocated directly in the old generation. The permanent generation holds objects that the JVM finds convenient to have the garbage collector manage, such as objects describing classes and methods,as well as the classes and methods themselves.
The young generation consists of an area called Eden plus two smaller survivor spaces.
Most objects are initially allocated in Eden. (As mentioned, a few large objects may be allocated directly in the old generation.) The survivor spaces hold objects that have survived at least one young generation collection and have thus been given additional chances to die before being considered “old enough” to be promoted to the old generation. At any given time, one of the survivor spaces (labeled From in the figure) holds such objects, while the other is empty and remains unused until the next collection.
Runtime Data Areas
The Java virtual machine defines various runtime data areas that are used during execution of a program. Some of these data areas are created on Java virtual machine start-up and are destroyed only when the Java virtual machine exits. Other data areas are per thread. Per-thread data areas are created when a thread is created and destroyed when the thread exits.
1. The pc Register
The Java virtual machine can support many threads of execution at once . Each Java virtual machine thread has its own pc (program counter) register . At any point, each Java virtual machine thread is executing the code of a single method, the current method for that thread. If that method is not native , the pc register contains the address of the Java virtual machine instruction currently being executed . If the method currently being executed by the thread is native , the value of the Java virtual machine's pc register is undefined. The Java virtual machine's pc register is wide enough to hold a returnAddress or a native pointer on the specific platform.
2. Java Virtual Machine Stacks
Each Java virtual machine thread has a private Java virtual machine stack , created at the same time as the thread. A Java virtual machine stack stores frames (§3.6) . A Java virtual machine stack is analogous to the stack of a conventional language such as C: it holds local variables and partial results, and plays a part in method invocation and return . Because the Java virtual machine stack is never manipulated directly except to push and pop frames, frames may be heap allocated. The memory for a Java virtual machine stack does not need to be contiguous.
The Java virtual machine specification permits Java virtual machine stacks either to be of a fixed size or to dynamically expand and contract as required by the computation. If the Java virtual machine stacks are of a fixed size, the size of each Java virtual machine stack may be chosen independently when that stack is created. A Java virtual machine implementation may provide the programmer or the user control over the initial size of Java virtual machine stacks, as well as, in the case of dynamically expanding or contracting Java virtual machine stacks, control over the maximum and minimum sizes.
The following exceptional conditions are associated with Java virtual machine stacks:
If the computation in a thread requires a larger Java virtual machine stack than is permitted, the Java virtual machine throws a StackOverflowError.
If Java virtual machine stacks can be dynamically expanded, and expansion is attempted but insufficient memory can be made available to effect the expansion, or if insufficient memory can be made available to create the initial Java virtual machine stack for a new thread, the Java virtual machine throws an OutOfMemoryError.
3. Heap
The Java virtual machine has a heap that is shared among all Java virtual machine threads. The heap is the runtime data area from which memory for all class instances and arrays is allocated.
The heap is created on virtual machine start-up . Heap storage for objects is reclaimed by an automatic storage management system (known as a garbage collector ) ; objects are never explicitly deallocated. The Java virtual machine assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the implementor's system requirements. The heap may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger heap becomes unnecessary. The memory for the heap does not need to be contiguous.
A Java virtual machine implementation may provide the programmer or the user control over the initial size of the heap, as well as, if the heap can be dynamically expanded or contracted, control over the maximum and minimum heap size.
The following exceptional condition is associated with the heap:
If a computation requires more heap than can be made available by the automatic storage management system, the Java virtual machine throws an OutOfMemoryError.
4. Method Area
The Java virtual machine has a method area that is shared among all Java virtual machine threads. The method area is analogous to the storage area for compiled code of a conventional language or analogous to the "text" segment in a UNIX process. It stores per-class structures such as the runtime constant pool, field and method data, and the code for methods and constructors, including the special methods(§3.9) used in class and instance initialization and interface type initialization.
The method area is created on virtual machine start-up . Although the method area is logically part of the heap , simple implementations may choose not to either garbage collect or compact it. This version of the Java virtual machine specification does not mandate the location of the method area or the policies used to manage compiled code. The method area may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger method area becomes unnecessary. The memory for the method area does not need to be contiguous.
A Java virtual machine implementation may provide the programmer or the user control over the initial size of the method area, as well as, in the case of a varying-size method area, control over the maximum and minimum method area size.
The following exceptional condition is associated with the method area:
If memory in the method area cannot be made available to satisfy an allocation request, the Java virtual machine throws an OutOfMemoryError.
5. Runtime Constant Pool
A runtime constant pool is a per-class or per-interface runtime representation of the constant_pool table in a class file . It contains several kinds of constants, ranging from numeric literals known at compile time to method and field references that must be resolved at run time. The runtime constant pool serves a function similar to that of a symbol table for a conventional programming language, although it contains a wider range of data than a typical symbol table.
Each runtime constant pool is allocated from the Java virtual machine's method area . The runtime constant pool for a class or interface is constructed when the class or interface is created by the Java virtual machine.
The following exceptional condition is associated with the construction of the runtime constant pool for a class or interface:
When creating a class or interface, if the construction of the runtime constant pool requires more memory than can be made available in the method area of the Java virtual machine, the Java virtual machine throws an OutOfMemoryError .
6. Native Method Stacks
An implementation of the Java virtual machine may use conventional stacks, colloquially called "C stacks," to support native methods, methods written in a language other than the Java programming language. Native method stacks may also be used by the implementation of an interpreter for the Java virtual machine's instruction set in a language such as C. Java virtual machine implementations that cannot load native methods and that do not themselves rely on conventional stacks need not supply native method stacks. If supplied, native method stacks are typically allocated per thread when each thread is created.
The Java virtual machine specification permits native method stacks either to be of a fixed size or to dynamically expand and contract as required by the computation. If the native method stacks are of a fixed size, the size of each native method stack may be chosen independently when that stack is created. In any case, a Java virtual machine implementation may provide the programmer or the user control over the initial size of the native method stacks. In the case of varying-size native method stacks, it may also make available control over the maximum and minimum method stack sizes.
The following exceptional conditions are associated with native method stacks:
If the computation in a thread requires a larger native method stack than is permitted, the Java virtual machine throws a StackOverflowError .
If native method stacks can be dynamically expanded and native method stack expansion is attempted but insufficient memory can be made available, or if insufficient memory can be made available to create the initial native method stack for a new thread, the Java virtual machine throws an OutOfMemoryError .
-Xms n
initial heap size
-Xmx n
maximum heap size
On machines that are not server-class machines, the default values for JVM, garbage collector, and heap sizes are
• the client JVM
• the serial garbage collector
• Initial heap size of 4MB
• Maximum heap size of 64MB
On a server-class machine, the JVM is always the server JVM unless you explicitly specify the -client command line option to request the client JVM. On a server-class machine running the server JVM, the default garbage collector is the parallel collector. Otherwise, the default is the serial collector.
On a server-class machine running either JVM (client or server) with the parallel garbage collector, the default initial and maximum heap sizes are
• Initial heap size of 1/64th of the physical memory, up to 1GB. (Note that the minimum initial heap size is 32MB, since a server-class machine is defined to have at least 2GB of memory and 1/64th of 2GB is 32MB.)
• Maximum heap size of 1/4th of the physical memory, up to 1GB.
-Xss n
Set thread stack size.
-XX:MaxPermSize =n
Maximum size of the permanent generation.
-XX:+UseSerialGC serial garbage collector (for smaller applications and systems)
-XX:+UseParallelGC parallel (throughput) garbage collector
-XX:+UseParallelOldGC Parallel compacting
-XX:+UseConcMarkSweepGC concurrent (low pause time) garbage collector (also known as CMS)
It is a parallel and mostly-concurrent collector and and can be a good match for the threading ability of an large multi-processor systems.
–XX:NewSize=n
Default initial size of the new (young) generation,in bytes.
–XX:NewRatio=n
Ratio between the young and old generations. For example, if n is 3, then the ratio is 1:3 and the combined size of Eden and the survivor spaces is one fourth of the total size of the young and old generations.
Generally speaking the largest recommended value for the young generation is 3/8 of the maximum heap size.
-XX:ParallelGCThreads =n
Reduces the number of garbage collection threads. The default would be equal to the processor count, which would probably be unnecessarily high on a 32 thread capable system.
-XX:SurvivorRatio =n
Ratio between each survivor space and Eden. Forexample, if n is 7, each survivor space is one–ninth of the young generation (not one–eighth, because there are two survivor spaces). Larger survivor spaces allow short lived objects a longer time period to die in the young generation.
-XX:MaxTenuringThreshold =31
Allows short lived objects a longer time period to die in the young generation (and hence, avoid promotion). A consequence of this setting is that minor GC times can increase due to additional objects to copy. This value and survivor space sizes may need to be adjusted so as to balance overheads of copying between survivor spaces versus tenuring objects that are going to live for a long time. The default settings for CMS are SurvivorRatio=1024 and MaxTenuringThreshold=0 which cause all survivors of a scavenge to be promoted. This can place a lot of pressure on the single concurrent thread collecting the tenured generation. Note: when used with -XX:+UseBiasedLocking, this setting should be 15.
-XX:+UseBiasedLocking
Enables a technique for improving the performance of uncontended synchronization. An object is "biased" toward the thread which first acquires its monitor via a monitorenter bytecode or synchronized method invocation; subsequent monitor-related operations performed by that thread are relatively much faster on multiprocessor machines. Some applications with significant amounts of uncontended synchronization may attain significant speedups with this flag enabled; some applications with certain patterns of locking may see slowdowns, though attempts have been made to minimize the negative impact.
-XX:+AggressiveOpts
Turns on point performance optimizations that are expected to be on by default in upcoming releases. The changes grouped by this flag are minor changes to JVM runtime compiled code and not distinct performance features (such as BiasedLocking and ParallelOldGC). This is a good flag to try the JVM engineering team's latest performance tweaks for upcoming releases. Note: this option is experimental! The specific optimizations enabled by this option can change from release to release and even build to build. You should reevaluate the effects of this option with prior to deploying a new release of Java.
-XX:+HeapDumpOnOutOfMemoryError
Dump heap to file when java.lang.OutOfMemoryError is thrown
-XX:HeapDumpPath=
Path to directory or filename for heap dump
参考文档
Memory Management in the Java HotSpot Virtual Machine
The Java® Virtual Machine Specification
How to solve java.lang.OutOfMemoryError: unable to create new native thread
相关推荐
建筑工地扬尘治理与文明施工检查表.docx
基于java的个性化旅游攻略定制系统设计与实现.docx
数学建模培训资料 数学建模实战题目真题答案解析解题过程&论文报告 导弹追击模型的建立与求解 共6页.pdf
基础课程辅助教学-JAVA-基于springBoot程序设计基础课程辅助教学系统设计与实现
适用人群:大学生 自学者 使用场景:大学生毕设 自学者练手项目 学习与交流 其它说明:部分资源来源网络及开源社区、仅供参考与学习、不可商用、若有侵权请联系删除! 内容概要:用springmvc实现的校园选课管理系统
java课程期末考试
C++ Vigenère 密码(解密代码)
工程研究中心申报基本情况一览表.docx
Vigenère 密码(加密代码)
密码学AES算法源代码,密码学实验
基于java的百货中心供应链管理系统设计与实现.docx
环境说明:开发语言:Java 框架:springboot JDK版本:JDK1.8 服务器:tomcat7 数据库:mysql 5.7 数据库工具:Navicat 开发软件:eclipse/myeclipse/idea Maven包:Maven 浏览器:谷歌浏览器。 项目均可完美运行
【资源说明】 大数据毕业设计 基于Python+Spark机器学习天气预测系统详细文档+全部资料.zip 【备注】 1、该项目是个人高分项目源码,已获导师指导认可通过,答辩评审分达到95分 2、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用! 3、本项目适合计算机相关专业(人工智能、通信工程、自动化、电子信息、物联网等)的在校学生、老师或者企业员工下载使用,也可作为毕业设计、课程设计、作业、项目初期立项演示等,当然也适合小白学习进阶。 4、如果基础还行,可以在此代码基础上进行修改,以实现其他功能,也可直接用于毕设、课设、作业等。 欢迎下载,沟通交流,互相学习,共同进步!
购物系统 微信小程序+PHP毕业设计 源码+数据库+论文+启动教程
BIM 人才培养的框架和方法 相关的标准
源项目文件
ActiveMQ消息中间件的测试案例
内容概要:本文全面解析了汽车电动化、智能化背景下,车规芯片SoC的重要性和发展趋势。首先概述了汽车行业发展三大趋势——新能源车市场崛起、智能化引领新潮流、商业模式及价值链重构。随后详细介绍了车规芯片SoC的应用领域,包括主控芯片、功率芯片、CMOS芯片、射频接收器、传感器、存储芯片及汽车面板,并阐述了它们的作用和技术需求。文章接着讨论了电子电气架构的演进路径,从分布式向集中式的演进对汽车芯片供应链带来的影响。最后探讨了汽车SoC的技术特征、应用领域、未来发展方向及其面临的挑战。 适合人群:汽车芯片设计师、汽车制造商、科研机构及相关行业的专业人士。 使用场景及目标:理解和掌握汽车芯片尤其是SoC在智能电动汽车中的应用及未来发展,帮助相关从业者做出更好的技术和商业决策。 其他说明:随着智能电动汽车市场的快速成长,车规芯片SoC作为核心技术将面临前所未有的机遇和挑战。
用于控制 Broadlink RM2/3 (Pro) 遥控器、A1 传感器平台和 SP2/3 智能插头的 Python 模块python-broadlink用于本地控制 Broadlink 设备的 Python 模块和 CLI。支持以下设备通用遥控器RM home、RM mini 3、RM plus、RM pro、RM pro+、RM4 mini、RM4 pro、RM4C mini、RM4S、RM4 TV mate智能插头SP mini、SP mini 3、SP mini+、SP1、SP2、SP2-BR、SP2-CL、SP2-IN、SP2-UK、SP3、SP3-EU、SP3S-EU、SP3S-US、SP4L-AU、SP4L-EU、SP4L-UK、SP4M、SP4M-US、Ankuoo NEO、Ankuoo NEO PRO、Efergy Ego、BG AHC/U-01开关MCB1、SC1、SCB1E、SCB2出口BG 800, BG 900电源板MP1-1K3S2U、MP1-1K4S、MP2环境传感器A1报警套件S1C、S2KIT灯泡LB1、LB26 R1、LB2
这是一份关于五个城市的PM2.5监测数据文件,以CSV格式存储。数据涵盖了广州、北京、沈阳等地的空气质量情况,旨在帮助研究人员和数据分析人员更好地理解城市空气污染状况。 使用人群 适合对环境科学、大气污染研究感兴趣的科研工作者、学生及环保组织成员使用。 数据内容 包含五个主要城市的PM2.5浓度数据 时间跨度较长,覆盖多年数据 CSV格式方便导入各种数据分析软件进行进一步处理和分析