Skip to content

Commit 221e299

Browse files
thread
1 parent 0bf806f commit 221e299

25 files changed

Lines changed: 1440 additions & 259 deletions

File tree

.gitignore

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,4 +5,5 @@
55
*/target/
66
*/.idea/
77
*.docs
8-
*.doc
8+
*.doc
9+
src/

notes/JVM/JVM笔记2.md

Lines changed: 83 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,83 @@
1+
## JVM监测工具
2+
3+
jps: 查看Java进程 (java命令)
4+
5+
jstat:只能查看当前时刻的内存情况;可以查看到 新生代、老年代中的内存使用情况
6+
7+
jmap:查看堆内存的占用情况;也可以执行dump操作
8+
9+
jconsole:图形的监控界面
10+
11+
​ 例如:如果通过jconsole中的"执行gc"按钮发现 GC回收的内存太少,就说明当前进程是存在问题的(至少是可以被优化的)
12+
13+
jvisualvm: 监视 - 堆Dump -查找最大对象,从中可以发现 当前进程中是哪个对象 占据了最大的内存,从而对这个对象进行分析。
14+
15+
通过VM参数实现: 当内存溢出时,自动将溢出时刻的内存dump下来。
16+
17+
-Xmx100m
18+
-Xms100m
19+
-XX:+HeapDumpOnOutOfMemoryError
20+
21+
22+
23+
## GC调优
24+
25+
Java开发者为什么不把所有的参数调到最优?非得让我们手工去调?
26+
27+
取舍。
28+
29+
调优实际是是一种取舍,以xx换xx的策略。因此在调优之前,必须明确方向:低延迟?高吞吐量呢?
30+
31+
有两种情况需要考虑:
32+
33+
1.在已知条件相同的前提下, 牺牲低延迟 来换取 高吞吐量,或者反之。
34+
35+
2.随着软件硬件技术的发展,可能 二者都升高。
36+
37+
38+
39+
GC的发展:
40+
41+
JVM自身在GC上进行了很多次的改进升级:
42+
43+
JVM默认的GC: CMS GC(在jdk9以后被逐步废弃) -> G1 GC(jdk9) -> Z GC(jdk11)
44+
45+
- Serial GC:
46+
47+
串行GC,是一种在单核环境下的串行回收器。当GC回收的时刻,其他线程必须等待。一般不会使用。
48+
49+
- Parallel GC:
50+
51+
在Serial 的基础上,使用 了多线程技术。 提高吞吐量。
52+
53+
- CMS GC
54+
55+
CMS使用了多线程技术,使用“标记-清除”算法,可以极大提升效率 (尤其在低延迟上有很大的提升)。繁琐,参数太多,对开发者的经验要求太高。
56+
57+
- G1 GC
58+
59+
jdk9开始使用的默认GC。特点:将堆内存划分为很多大小相等region,并会对这些区域的使用状态进行标记。以便GC在回收时,能够快速的定位出哪些region是空闲的,哪些是有垃圾对象,从而提升GC的效率。G1使用的算法是“标记-整理”算法。
60+
61+
- Z GC
62+
63+
jdk11开始提供全新的GC。回收TB级别的垃圾 在毫秒范围。
64+
65+
66+
67+
68+
69+
如果从生命周期角度划分,GC也可以划分成:Minor GC,和Full GC
70+
71+
- Minor GC:回收新生代中的对象
72+
- Full GC:回收整个堆空间(新生代、老年代)
73+
74+
案例:
75+
76+
如果通过监测工具发现: Minor GC和Full GC都在频繁的回收,如何优化?
77+
78+
Minor GC为什么会频繁执行?因为 新生代中的对象太多了 Minor GC->短生命周期的对象太多了->造成逃逸到老年代中的对象越多-> 新生代多+老年代多->Full GC
79+
80+
Minor GC:可以尝试调大 新生代的最大空间
81+
82+
再调大 新生代晋升到老年代的阈值,从而降低 短生命周期的对象 从新生代转移到老年代的概率。
83+
17.2 KB
Loading
17.4 KB
Loading

notes/JVM/jvm笔记.md

Lines changed: 20 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -294,7 +294,7 @@ public static void main(String[] args) {
294294

295295
- 新生代:存放 1.生命周期比较短的对象 2.小的对象;反之,存放在老生代中。对象的大小,可以通过参数设置 -XX:PretenureSizeThredshold 。一般而言,大对象一般是 集合、数组、字符串。生命周期: -XX:MaxTenuringThredshold
296296

297-
新生代、老生代中年龄:MinorGC回收新生代中的对象。如果Eden区中的对象在一次回收后仍然存活,就会被转移到 s区中;之后,如果MinorGC再次回收,已经在s区中的对象仍然存活,则年龄+1。如果年龄增长一定的数字,则对象会被转移到 老生代中(默认是16)。简言之:在新生代中的对象,没经过一次MinorGC,有三种可能:1从eden -》s区 2.(已经在s区中)年龄+1 3.转移到老生代中
297+
新生代、老生代中年龄:MinorGC回收新生代中的对象。如果Eden区中的对象在一次回收后仍然存活,就会被转移到 s区中;之后,如果MinorGC再次回收,已经在s区中的对象仍然存活,则年龄+1。如果年龄增长一定的数字,则对象会被转移到 老生代中。简言之:在新生代中的对象,每经过一次MinorGC,有三种可能:1从eden -》s区 2.(已经在s区中)年龄+1 3.转移到老生代中
298298

299299
![1568946567405](jvm笔记.assets/1568946567405.png)
300300

@@ -922,7 +922,7 @@ public class MyClassLoader {
922922
- JVM自带的加载器
923923

924924
- 根加载器,Bootstrap : 加载 jre\lib\rt.jar (包含了平时编写代码时 大部分jdk api);指定加载某一个jar( -Xbootclasspath=a.jar)
925-
- 扩展类加载器,Extension:C:\Java\jdk1.8.0_101\jre\lib\ext /\*.jar ;指定加载某一个jar(-Djava.ext.dirs= ....)
925+
- 扩展类加载器,Extension:C:\Java\jdk1.8.0_101\jre\lib\ext\\\*.jar ;指定加载某一个jar(-Djava.ext.dirs= ....)
926926
- AppClassLoader/SystemClassLoader,系统加载器(应用加载器):加载classpath;指定加载(-Djava.class.path= 类/jar)
927927

928928
- 用户自定义的加载器
@@ -1635,3 +1635,21 @@ java.lang.NoClassDefFoundError: com/yanqun/parents/Y
16351635

16361636
如果都在同一个加载器 ,则不存在加载问题; 如果不是同一个,就需要双亲委派。
16371637

1638+
如果想实现各个加载器之间的自定义依赖,可以使用ogsi规范
1639+
1640+
![1572660850713](jvm笔记.assets/1572660850713.png)
1641+
1642+
OSGi:
1643+
1644+
1.网状结构的加载结构
1645+
1646+
2.屏蔽掉硬件的异构性。例如,可以将项目部署在网络上,可以在A节点上 远程操作B节点。在操作上,可以对硬件无感。也可以在A节点上 对B节点上的项目进行运维、部署,并且立项情况下 在维护的期间,不需要暂时、重启。
1647+
1648+
1649+
1650+
### 类的卸载
1651+
1652+
1.系统自带(系统加载器、扩展加载器、根加载器):这些加载器加载的类 是不会被卸载。
1653+
1654+
2.用户自定义的加载器,会被GC卸载GC
1655+
17.2 KB
Loading

0 commit comments

Comments
 (0)