Skip to content

Commit 221e299

Browse files
coding-technologycoding-technology
committed
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+

‎notes/JVM/jvm笔记.assets/1572660850713.png‎

17.2 KB
Loading

‎notes/JVM/jvm笔记.assets/1572660856526.png‎

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+

‎notes/thread/多线程.assets/1574068114471.png‎

17.2 KB
Loading

0 commit comments

Comments
 (0)