Java Common problems analysis

I. Introduction of the JVM
1.JVM Memory model
Actual memory Size:-xx:maxpermsize +-xmx +-XSS +-xx:maxdirectmemorysize
One:

Mainly divided into: non-heap memory + heap memory + stack memory + out-of-heap memory
The JVM primarily manages two types of memory: heap and non-heap. In a nutshell, a heap is a Java-code memory that is left to developers to use, not heaps that the JVM has left for itself.
Memory outside the heap in the JVM is called Non-heap memory (non-heap memories).
Java virtual machines have a heap, which is a run-time data region where all class instances and arrays of memory are allocated. The heap is created when the Java Virtual machine is started.
Out-of-heap memory: Directmemory is introduced by Java NIO and allocates memory directly in a native way, and is not managed by the JVM. This is done in order to improve the efficiency of the network and file IO and avoid unnecessary memory duplication.
Stack: Each thread executes each method by applying a stack frame in the stack, each of which includes a local variable area and an operand stack for storing temporary variables, parameters, and intermediate results during the method call.

2. Heap memory divided into three generations
This is divided into: young Generation, Old Generation tenured, and persistent generation (Permanent Generation).
Persistent generations primarily store class information for Java classes and are not related to the Java objects that garbage collection collects. The division of the younger generation and the old generation is more significant for garbage collection.
Young generation: [Eden/survisor/survisor]
All newly generated objects are first placed in the younger generation. The goal of the young generation is to collect as quickly as possible those objects with short life cycles.
The young generation is divided into three districts. One Eden area, two survivor districts (in general). Most objects are generated in the Eden area. When the Eden Zone is full, the surviving objects will be copied to the Survivor area (one of two), and when the survivor area is full, the surviving objects of this area will be copied to another survivor area, when the survivor is full, Objects that are copied from the first survivor area and that are still alive will be duplicated in the old Age zone (tenured). It should be noted that the two areas of the survivor are symmetrical and have no relationship, so the same area may exist at the same time from Eden copied objects, and from the previous survivor copied objects, and copied to the old quarter only from the first survivor to come over the object. Moreover, there is always an empty survivor area. At the same time, according to the program needs, the survivor area can be configured as multiple (more than two), which can increase the time of the object in the younger generation, reduce the possibility of being put into the old generation.
Old generation:
Objects that survived after n garbage collection in the younger generation will be placed in the old age. Therefore, it can be considered that older generations are storing objects with longer life cycles.
Persistent Generations:
Used to store static files, now Java classes, methods, and so on. The persistence generation has no significant impact on garbage collection, but some applications may dynamically generate or invoke some classes, such as Hibernate, at which point a large, persistent generation space is required to store the new class in these runs. The persistent generation size is set by-xx:maxpermsize=<n>.
The new generation and the old age are all piles of memory space
Heap of memory models:
[Eden|from|to]-[old]
\__young____/--\old/
The default edem:from:to=8:1:1 (can be set by the parameter –xx:survivorratio), namely: EDEN=8/10 's New Generation (young) space size, FROM=TO=1/10 's Cenozoic space size.
New Generation (Young) = 1/3 of the heap space size. The old age = 2/3 heap space size. Among them, the new generation (young)

3.GC
Scavenge GC
In general, when a new object is generated and the Eden application space fails, the scavenge GC is triggered, GC is performed on the Eden Zone, the non-surviving objects are cleared, and the surviving objects are moved to the survivor area. Then tidy up the two districts of survivor. This method of GC is carried out on the young generation of the Eden area and does not affect the old generation. Because most objects start in the Eden area, and the Eden area is not very large, GC in the Eden area is frequent. Thus, it is generally necessary to use fast and efficient algorithms, so that Eden can be free as soon as possible.
The new generation usually has a shorter time to live, so the so-called replication algorithm is to scan out the surviving object and copy it into a completely unused space, corresponding to the Cenozoic, which is in Eden and one of the survivor, copied to the other survivor space, Then clean out the object that was in Eden and one of the survivor. The Cenozoic uses a free pointer to control the GC trigger, the pointer keeps the last allocated object in the Cenozoic interval, and when a new object is allocated memory, it is used to check if the space is sufficient and not enough to trigger the GC. When objects are allocated continuously, the objects gradually go from Eden to Survivor, and finally to the old age.
Full GC
Organize the entire heap, including young, tenured and perm. The full GC is slower than the scavenge GC because it needs to be recycled for the entire pair, so it should be as low as possible. In the process of tuning the JVM, a large part of the work is to adjust the FULLGC. The full GC may be caused by the following reasons:
The old generation and the new generation, the object survival time is longer, more stable, so the mark (Mark) algorithm for recycling, so-called Mark is to scan out the surviving objects, and then to reclaim unmarked objects, after recycling the empty space is either merged, or marked out for the next allocation, The bottom line is to reduce the loss of efficiency caused by memory fragmentation.
The old generation (tenured) was written full
Persistent generation (Perm) is full
System.GC () is displayed call
Dynamic changes in the domain allocation policy of the heap after the last GC

GC mode provided by 4.JVM
The JVM provides serial GC (SERIALGC), parallel reclaim GC (Parallelscavenge), and parallel GC (PARNEW)
1) Serial GC
The entire scanning and copying process is a single-threaded way, suitable for single CPU, the new generation of small space and the demand for pause time is not very high application, is the client level of the default GC mode, can be-XX:+USESERIALGC to enforce the specified
2) Parallel Recovery GC
In the entire scanning and replication process in a multi-threaded way, for multi-CPU, the time required for a short pause on the application, the server level is the default use of GC mode, can be-XX:+USEPARALLELGC to enforce the designation, with-XX: Parallelgcthreads=4 to specify the number of threads
3) Parallel GC
Use with concurrent GC for legacy generations
Two:

Two, Java FAQ processing
1. Process exception exits
=======================================
Possible causes:
1) system Oom Killer//grep kill/var/ Log/messages, see memory consumption Total-vm,anon-rss,file-rss
2) for kill kill //history |grep-i kill
3) Code substitution System.exit ()//Reverse Code
4) JVM itself bug//directmemory default size is 64M, and JDK6 before and some versions of JDK6 Sun JVM, there is a bug, in-XMX set the size of the heap space , the size of the directmemory is also set. With the-xmx2048m set, the JVM can eventually allocate more than 4G of memory, which is twice times the expected size. The
workaround is to set the JVM parameter-xx:maxdirectmemorysize=128m, specifying the size of the directmemory.
5) Memory issues     //memory shortage, such as the time to request a large object. Cannot be timely GC
6) native stack overflow causes//is not controlled by the JVM, but when the Java-occupied
Fatal error occurs, the JVM generates a file such as Hs_err_pid<pid>.log. This often contains important information about the cause of the virtual machine crash
created in working directory by default: Can be combined with find-name hs_err_pid*
Hs_err_pid<pid>.log file contents

1) Trigger fatal error operation exception or signal 2) version and configuration information 3) trigger fatal exception thread details and line stacks 4) current running thread list and their status 5) heap of summary information 6) loaded local library 7) command line parameter 8) environment variable 9) OS CPU information

2.OOM
=======================================
s) Java heap SPACE/GC overhead limit exceededDump Analysis: Startup parameter-xx:+heapdumponoutofmemoryerror-xx:heapdumppath= or jmap-dump:format=b,file= filename [PID]
Analyze Heapdump with the mat tool
Memory-Intensive Code optimization
If the memory footprint is not large: it may be that a big object is created, and the time of the large object is created based on log analysis/jstack analysis of the existence of a dead loop
2) PermGen space
Big PermSize
Whether to dynamically load groovy scripts
Is there a dynamic generation of class logic, such as a large number of dynamically generated classes using Cglib
3) Direct Buffer Memory
Default consumption-xmx the same memory//-xx:maxdirectmemorysize=1g adjustment
Network traffic uses Netty but no current limit
Analyze code for use of Directybuffer not properly controlled
4) Java.lang.StackOverflowError
Small-XSS to reduce the memory footprint of each thread stacks//set the stack size
Adjust the-xmx, give the stack more memory space
Analyze code for unreasonable recursion
5) Request bytes for out of swap space
Not enough address space//64bitos
Insufficient physical memory: jmap-histo:live PID, if memory is significantly reduced, the description is directbuffer problem, through-xx:maxdirectmemorysize settings
Btrace Inflater/deflater
6) Unable to create new native thread
Ulimit-a//vim/etc/security/limits.conf Add
* Soft Noproc 11000
* Hard Noproc 11000
* Soft Nofile 5000//Modify limit
* Hard Nofile 5000//Modify limit
/proc/sys/kernel/pid_max number of operating system threads limit
/proc/sys/vm/max_map_count single-process mmap limits can affect
/proc/sys/kernel/thread-max
/proc/sys/vm/max_map_count
Max_user_process (Ulimit-u)

7) Map failed
Three:

3.CPU too high
=======================================
Basic command: Top,vmstat,mpstat,sar,tsar
US High: User processes consume more CPU time
Cause: Full Gc,cms GC, code dead Loop, total CPU consumption, etc.
Scenario: View gc.log; Jstat-gcutil [PID]//https://github.com/oldratlee/useful-scripts/blob/master/show-busy-javathreads.sh
Sy High: The kernel consumes more CPU time
Reason: Lock competition is fierce, thread active switch frequently
Scenario: Jstack See if there are locks, or if thread switching is frequent. Change to lock-free structure, switch thread switch to notification mechanism frequently
Btrace Conditionobject.awaitnanos Whether there is a small value, preferably MS level
WA High: More CPU time waiting for IO, too many random io, or disk performance issues
Cause: IO Read and write frequently
Scenario: iostat,iotop,lsof//increase cache, synchronize to asynchronous, random write to sequential

4. Application Not Responding
=======================================
High CPU
OOM
Deadlock Jstack-l View the thread that corresponds to the deadlock//remove the deadlock,
Line Cheng//increase thread pool to reduce time-consuming

5. Environment variable exception
=======================================
Time zone error/Variable error/Wrong coding method
Solution:
Jinfo viewing the specific startup parameters

6. Call Timeout
=======================================
Server side slow/server or call end gc/server or caller CPU high/large object serialization slow/network problem, packet loss

=======================================
third, case analysis
Case one: "PermGen space"
Java.lang.OutOfMemoryError:PermGen Space
Exception in thread "http-bio-17788-exec-75"
It is obvious that the memory overflow of the old age indicates that there are too many static files under the container, such as compiled bytecode, JSP compiled into servlet, or jar package.
To resolve this problem, modify the JVM parameter permsize, permsize initial default is 64m.

-vmargs-xms128m-xmx512m-xx:permsize=64m-xx:maxpermsize=128m
The-vmargs description is followed by the parameters of the VM, so the following are actually the parameters of the JVM
-xms128m JVM Initial allocation of heap memory
-XMX512M JVM Maximum allowable allocated heap memory, on demand
-xx:permsize=64m JVM Initial allocation of non-heap memory
-xx:maxpermsize=128m JVM Maximum allowable allocated non-heap memory, on demand

Http://makaidong.com/gsycwh/1/147114_9379890.html
Heartfelt thanks: Seawater classmate support.

Java Common problems analysis