update

docs/java/JVM/zgc.md

@@ -1,6 +1,6 @@
 # ZGC
 
-本文转载自[12 张图带你彻底理解 ZGC](https://zhuanlan.zhihu.com/p/474527679)
+*本文转载自[12 张图带你彻底理解 ZGC](https://zhuanlan.zhihu.com/p/474527679)*
 
 ZGC（Z Garbage Collector） 是一款性能比 G1 更加优秀的垃圾收集器。ZGC 第一次出现是在 JDK 11 中以实验性的特性引入，这也是 JDK 11 中最大的亮点。在 JDK 15 中 ZGC 不再是实验功能，可以正式投入生产使用了，使用 –XX:+UseZGC 可以启用 ZGC。
 

docs/java/JVM/常用GC回收器.md

@@ -10,4 +10,45 @@
 | ZGC (Z Garbage Collector)   | 标记-整理                       | 老年代 |
 | Shenandoah                  | 标记-复制（独立的全局复制阶段） | 老年代 |
 
-上述表格展示了一些主流垃圾回收器所采用的GC算法。值得注意的是，一些回收器可能会组合使用不同的算法，或者在特定阶段采用特定的算法，以优化性能和内存利用。这种选择通常取决于应用程序的特性和性能需求。
+上述表格展示了一些主流垃圾回收器所采用的GC算法。值得注意的是，一些回收器可能会组合使用不同的算法，或者在特定阶段采用特定的算法，以优化性能和内存利用。这种选择通常取决于应用程序的特性和性能需求。
+
+
+## 是否可以使用两种或多种垃圾回收器
+在Java中，你不能同时使用两种不同的垃圾回收器。Serial和G1是两种不同的垃圾回收器，它们有不同的设计目标和使用场景。
+
+Serial垃圾回收器是一个单线程的垃圾回收器，它在进行垃圾回收时会暂停所有的应用线程。这种垃圾回收器适合于单核处理器或者内存较小的系统。
+
+G1垃圾回收器是一种并行和并发的垃圾回收器，它可以处理大量的堆内存并且尽量减少垃圾回收引起的暂停时间。G1垃圾回收器适合于多核处理器和内存较大的系统。
+
+如果你想在你的应用中使用某种垃圾回收器，你可以通过JVM的命令行选项来指定，例如"-XX:+UseSerialGC"可以启用Serial垃圾回收器，"-XX:+UseG1GC"可以启用G1垃圾回收器。但是你不能同时启用两种垃圾回收器。
+
+## 查看java进程用的是哪种垃圾回收器
+首先，你需要找到你的Java进程的进程ID。你可以使用jps命令来列出所有的Java进程和它们的进程ID。
+
+然后，你可以使用jinfo -flags 进程ID命令来查看Java进程的JVM标志。在输出的信息中，你可以找到-XX:+UseXXXGC这样的标志，这个标志表示Java进程使用的垃圾回收器。例如，如果你看到-XX:+UseG1GC，那么这个Java进程就是使用G1垃圾回收器。
+样例：
+```shell
+[root@xxxx-1-b68d78f6d-b9nnq /data/logs]# jinfo -flags 4868
+VM Flags:
+-XX:CICompilerCount=2 -XX:ConcGCThreads=1 -XX:G1ConcRefinementThreads=2 -XX:G1HeapRegionSize=1048576 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=2147483648 -XX:MarkStackSize=4194304 -XX:MaxHeapSize=2147483648 -XX:MaxNewSize=1287651328 -XX:MinHeapDeltaBytes=1048576 -XX:NonNMethodCodeHeapSize=5826188 -XX:NonProfiledCodeHeapSize=122916026 -XX:ProfiledCodeHeapSize=122916026 -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseG1GC
+```
+
+## 怎么查看java进程eden、survivor等各个区的内存占用
+用jstat -gc 进程ID命令来查看Java进程的堆内存使用情况。这个命令会显示一些列的数据，包括：
+
+S0C、S1C、S0U、S1U：Survivor 0和Survivor 1区的当前容量（Capacity）和使用量（Used）。
+EC、EU：Eden区的当前容量和使用量。
+OC、OU：Old区的当前容量和使用量。
+MC、MU：元数据区的当前容量和使用量。
+CCSC、CCSU：压缩类空间的当前容量和使用量。
+这些数据都是以KB为单位的。你可以通过这些数据来了解Java进程的堆内存使用情况。
+样例：
+```shell
+[root@xxxx-1-b68d78f6d-b9nnq /data/logs]# jstat -gc  4868
+ S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT    CGC    CGCT     GCT   
+ 0.0   5120.0  0.0   5120.0 1315840.0 871424.0  776192.0   300002.0  123212.0 117919.3 14464.0 12606.6  68825 1274.741   0      0.000  46      0.664 1275.405
+```
+
+
+## 参考：
+1.[儒猿课堂](https://space.bilibili.com/478364560/article)

docs/java/JVM/调优思路.md

@@ -0,0 +1,26 @@
+---
+index: false
+---
+# JVM调优思路
+在项目开发过程中、生产环境中，任何问题的解决、性能的调优总结下来都是三个步骤，即发现问题、定位问题、解决问题，本文将从这个步骤入手，详细阐述内存溢出（OOM、OutOfMemeory）、CPU飙高、GC频繁等JVM问题的排查、定位，以及调优。
+
+1.监控发现问题
+2.工具分析问题
+3.性能调优
+下面开始一步步讲解
+
+## 一、监控发现问题
+通过监控工具例如Prometheus+Grafana，监控服务器有没有以下情况，有的话需要调优：
+
+GC频繁
+CPU负载过高
+OOM
+内存泄露
+死锁
+程序响应时间较长
+
+## 二、工具分析问题
+
+
+## 参考
+1.[【JVM调优】如何进行JVM调优？一篇文章就够了！](https://blog.csdn.net/qq_40991313/article/details/132382094)

docs/kubernetes/request_limit.md

@@ -0,0 +1,25 @@
+# Kubernetes之request 和 limit详解
+我们都知道 Kubernetes 中最小的原子调度单位是Pod，那么就意味着资源管理和资源调度相关的属性都应该Pod对象的字段，其中我们最常见的就是 Pod 的 CPU 和内存配置，而为了实现 Kubernetes 集群中资源的有效调度和充分利用，Kubernetes采用 requests 和 limits 两种限制类型来对CPU和内存资源进行容器粒度的分配。
+
+```yaml
+resources:  
+    limits:    
+        cpu: "1"
+        memory: "500Mi"
+    requests:    
+        cpu: "100m"
+        memory: "1000Mi"
+```
+下面我们首先来了解一下上面这段 yaml 文件中字段的含义：requests 和 limits：
+
+**requests 定义了对应的容器所需要的最小资源量。**
+**limits 定义了对应容器最大可以消耗的资源上限。**
+cpu 等于1一般等同于1CPU 核心，1个VCPU或者一个超线程，具体要看服务器的CPU。而 limits 这里设置的 100m 则叫做100毫核，100m就表示0.1个核,所以这里也可以用0.1代替。
+memory 等于500Mi，（备注：1Mi=10241024；1M=10001000）
+接下来我们来初步理解 requests 和 limits 这两个资源限制类型，在 Kubernetes 对 CPU 和内存资源限额的设计，通常是指用户在提交 Pod 时，可以声明一个相对较小的 requests 值供调度器使用，而 Kubernetes 真正设置给容器 Cgroups 的，则是相对较大的 limits 值。所以一般来说，在调度的时候 requests 比较重要，在运行时 limits 比较重要。
+
+而对应实际的业务场景来说，以 java 应用为例，requests 对应的就是JVM虚拟机所需资源的最小值，而 limits 对应的就是 JVM 虚拟机所能够使用的资源最大值。以内存资源为例一般就是指：Xms 和 Xmx，如果 requests 值设置的小于JVM虚拟机 Xms 的值，那么就会导致 Pod 内存溢出，从而导致 Pod 被杀掉，而后重新创建一个Pod。
+
+那么如果 CPU 资源使用超过了 limits，Pod会不会被杀掉呢？答案是不会，但是被限制。如果没有设置 limits ，Pod 可以使用全部空闲的资源。另外如果设置了 limits而没有设置 requests 时，Kubernetes 默认会将 requests 等于 limits。
+
+这里通常还会将 requests 和 limits 描述的资源分为两类：可压缩资源（compressible resources） 和不可压缩资源（incompressible resources）。这里不难看出CPU这类型资源为可压缩资源，而内存这类型资源为不可压缩资源。所以合理设置不可压缩资源的limits值就相当重要了。