Parameter setting background
In Java development, especially large-scale software development often encounter memory overflow problems, such as OutOfMemoryError. This is a painful and tangled issue for developers, because we sometimes don't know what kind of operation is causing the problem. So we have to constantly review and optimize our code structure. But sometimes we find that there are times when it's not just about refactoring our own code to solve this problem, because it's also possible that our memory allocations to the Java Virtual Runtime are not going to cause the memory overflow to happen constantly.
To solve this problem, the Java development team provides a user-defined way to configure the required memory of the Java virtual runtime as needed-to implement parameter assignment customizations in the form of parameter configurations.
The JVM allocates the required memory according to the contents of its stored data as
Heap AreaAnd
non-heap areaTwo parts:
- The heap area is the memory space that is occupied by objects (class instances) created by means of new
- non-heap zones are code, constants, external access (e.g., resources for file access streams), etc.
Although Java's garbage collection mechanism can solve the problem of memory waste, this mechanism is only the recycling
Heap AreaResources, and the resources for non-heap areas are helpless, and for such resource recycling can only be solved by the developer's own constraints. Even if this is the case (the heap has a Java recycle mechanism, the non-heap developers can solve it well), when the runtime requires
Instant Memory SurgeWhen the JVM is helpless to abort the operation of the program. So this article is about how to solve the latter problem. Common parameter types (configuration memory)
- Configuring the heap area:-xms,-xmx,-xx:newsize,-xx:maxnewsize,-xmn
- Configuring Non-heap zones:-xx:permsize,-xx:maxpermsize
Heap Zone parameter configuration
1.-XMS: Represents the size of the initial memory allocation for the Java Virtual machine heap memory, typically 1/64 of the operating system's available memory, but still needs to be allocated in the actual situation. It's possible that the design of the software has not been able to run and hang up when it is actually distributed according to such a rule.
2.-XMX: Represents the maximum amount of Java Virtual machine heap memory that can be allocated, typically 1/4 of the operating system's available memory. However, in the development process, the-XMS is typically configured with the same value as the-xmx two parameter, which is intended to waste resources after the Java garbage collection mechanism does not need to re-partition the size of the compute heap after the heap is cleaned up. In general, for the memory allocation of the heap area, only the above two parameters should be properly configured.
non-heap zone parameter configuration
1.-xx:permsize: Represents the non-heap initial memory allocation size, abbreviated to permanent size (persisted memory)
2.-xx:maxpermsize: Represents the maximum amount of memory allocated to a non-heap area
Note: Be sure to consider the amount of non-heap memory required by your software before configuring it, as memory is not handled by the Java garbage collection mechanism. It is also more important to note that the maximum heap memory and the maximum non-heap memory and absolutely not enough to exceed the operating system's available memory. Reference: http://blog.csdn.net/kok1992/article/details/44774967
Java-xms-xmx-xx:permsize-xx:maxpermsize differences
