深入k8s：Kubernetes持久卷PV、PVC及源码分析(1)

storage: 1Gi

accessModes:

• ReadWriteOnce

• ReadOnlyMany

persistentVolumeReclaimPolicy: Retain

gcePersistentDisk:

pdName: mongodb

fsType: ext4

这个 PV 对象中会详细定义存储的类型是GCE，以及大小是1 GiB，这里没有声明storageClassName，是因为storageClassName默认就为空。

然后我们看一下PV和PVC的状态：

$ kubectl get pv

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE

mongodb-pv 1Gi RWO,ROX Retain Bound default/mongodb-pvc 77m

$ kubectl get pvc

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE

mongodb-pvc Bound mongodb-pv 1Gi RWO,ROX 7m7s

可以看到PV和PVC已经相互绑定了。

PVC和PV相当于“接口”和“实现”，所以我们需要将PVC和PV绑定起来才可以使用，而PVC和PV绑定的时候需要满足：

1. PV 和 PVC 的 spec 字段要匹配，比如PV 的存储（storage）大小，就必须满足 PVC 的要求。

2. PV 和 PVC 的 storageClassName 字段必须一样才能进行绑定。storageClassName表示的是StorageClass的name属性。

如果我们想要在Pod中使用这个PVC，那么我们可以这么做：

apiVersion: v1

kind: Pod

metadata:

name: mongodb

spec:

containers:

• image: mongo

name: mongodb

volumeMounts:

• name: mongodb-data

mountPath: /data/db

ports:

• containerPort: 27017

protocol: TCP

volumes:

• name: mongodb-data

persistentVolumeClaim:

claimName: mongodb-pvc

在Pod中只需要声明PVC的名字，等Pod创建后kubelet 就会把这个 PVC 所对应的 PV，也就是一个 GCE类型的 Volume，挂载在这个 Pod 容器内的目录上。

PersistentVolumeController会不断地查看当前每一个 PVC，是不是已经处于 Bound（已绑定）状态。如果不是，那它就会遍历所有的、可用的 PV，并尝试将其与这个“单身”的 PVC 进行绑定。这个PersistentVolumeController的源码我们下面会进行分析。那么问题来了，k8s为什么要将一个存储卷分成两部分呢？

因为实际上，我们项目当中，研发人员和集群的管理人员是分开的，研发人员只管使用，但是并不关心底层到底用的是什么存储技术，所以研发人员只要声明一个PVC，表示我需要多大的一个存储，以及读写类型就可以了。

StorageClass的Dynamic Provisioning

在上面我们说的PV和PVC绑定的过程称为Static Provisioning，需要手动的创建PV，我们在研发中可能有这样的情况，就是管理员没有及时给我们创建对应的PV，难道一直等着吗？所以这个时候就需要用到StorageClass了，StorageClass提供了Dynamic Provisioning机制，可以根据模板创建PV。

StorageClass 对象会定义如下两个部分内容：

1. PV 的属性。比如，存储类型、Volume 的大小等等。

2. 创建这种 PV 需要用到的存储插件。比如，Ceph 等等。

这样k8s就能够根据用户提交的 PVC，找到一个对应的 StorageClass ，然后调用该 StorageClass 声明的存储插件，创建出需要的 PV。

例如声明如下StorageClass：

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

name: block-service

provisioner: kubernetes.io/gce-pd

parameters:

type: pd-ssd

这里定义了名叫 block-service 的 StorageClass，provisioner 字段的值是：kubernetes.io/gce-pd，这是k8s内置的存储插件，type字段也是跟着provisioner定义的，官方默认支持 Dynamic Provisioning 的内置存储插件

然后就可以在PVC中声明storageClassName为block-service，当创建好PVC 对象之后，k8s就会调用相应的存储插件API创建一个PV对象。

如下：

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: claim1

spec:

accessModes:

• ReadWriteOnce

storageClassName: block-service

resources:

requests:

storage: 30Gi

这种自动创建PV的机制就是Dynamic Provisioning，Kubernetes 就能够根据用户提交的 PVC，找到一个对应的 StorageClass ，然后会调用StorageClass 声明的存储插件，创建出需要的 PV。

需要注意的是，如果没有声明StorageClassName在PVC中，PVC 的 storageClassName 的值就是"“，这也意味着它只能够跟 storageClassName 也是”"的 PV 进行绑定。

PV和PVC的生命周期

PV和PVC之间的相互作用遵循这个生命周期:

Provisioning —>Binding —>Using —>Reclaiming

Provisioning

k8s提供了两种PV生成方式： statically or dynamically

statically：由管理员创建PV，它们携带可供集群用户使用的真实存储的详细信息。 它们存在于Kubernetes API中，可用于消费。

dynamically：当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时，集群可能会尝试为PVC动态配置卷。 此配置基于StorageClasses，PVC必须请求一个StorageClasses，并且管理员必须已创建并配置该类才能进行动态配置。

Binding

由用户创建好PersistentVolumeClaim 后，PersistentVolumeController会不断地查看当前每一个 PVC，是不是已经处于 Bound（已绑定）状态。如果不是，那它就会遍历所有的、可用的 PV，并尝试将其与这个“单身”的 PVC 进行绑定。

Using

Pods声明并使用PVC作为volume后，集群会找到该PVC，如果该PVC已经绑定了PV，那么会将该volume挂载到Pod中。

Reclaiming

当用户已经不再使用该volume，可以将该PVC删除，以便让资源得以回收。相应的在PVC删除后，PV的回收策略可以是Retained, Recycled, or Deleted，这个策略可以在字段spec.persistentVolumeReclaimPolicy中设置。

• Retain：这个策略允许手动回收资源，当PVC被删除后，PV仍然可以存在，管理员可以手动的执行删除PV，并且和PV绑定的存储资源也不会被删除，如果想要删除相应的存储资源的数据，需要手动删除对应存储资源的数据。

• Delete：这个策略会在PVC被删除之后，连带将PV以及PV管理的存储资源也删除。

• Recycle：相当于在volume中执行rm -rf /thevolume/*命令，以便让volume可以重复利用。

一般的情况下，我们遵循这个删除流程：

1. 删除使用这个 PV 的 Pod；

2. 从宿主机移除本地磁盘（比如，umount 它）；

3. 删除 PVC；

4. 删除 PV。

源码分析

PV和PVC的源码处理逻辑都在pv_controller_base.go和pv_controller.go这两个文件中。我们直接看核心代码是怎样的。

首先来看看PersistentVolumeController的Run方法，这是入口：

func (ctrl *PersistentVolumeController) Run(stopCh <-chan struct{}) {

…

go wait.Until(ctrl.resync, ctrl.resyncPeriod, stopCh)

go wait.Until(ctrl.volumeWorker, time.Second, stopCh)

go wait.Until(ctrl.claimWorker, time.Second, stopCh)

…

}

这个代码主要就是起了三个Goroutine，分别运行不同的方法。resync方法十分简单，主要作用是找出pv和pvc列表然后放入到队列volumeQueue和claimQueue中，给volumeWorker和claimWorker进行消费。所以下面我们主要看volumeWorker以及claimWorker

volumeWorker

volumeWorker会不断循环消费volumeQueue队列里面的数据，然后获取到相应的PV执行updateVolume操作。

func (ctrl *PersistentVolumeController) updateVolume(volume *v1.PersistentVolume) {

// Store the new volume version in the cache and do not process it if this

// is an old version.

//更新缓存

new, err := ctrl.storeVolumeUpdate(volume)

if err != nil {

klog.Errorf(“%v”, err)

}

if !new {

return

}

//核心方法，根据当前 PV 对象的规格对 PV 和 PVC 进行绑定或者解绑

err = ctrl.syncVolume(volume)

if err != nil {

if errors.IsConflict(err) {

// Version conflict error happens quite often and the controller

// recovers from it easily.

klog.V(3).Infof(“could not sync volume %q: %+v”, volume.Name, err)

} else {

klog.Errorf(“could not sync volume %q: %+v”, volume.Name, err)

}

}

}

updateVolume方法会调用syncVolume方法，执行核心流程。

我们继续：

func (ctrl *PersistentVolumeController) syncVolume(volume *v1.PersistentVolume) error {

klog.V(4).Infof(“synchronizing PersistentVolume[%s]: %s”, volume.Name, getVolumeStatusForLogging(volume))

…

//如果spec.claimRef未设置，则是未使用过的pv，则调用updateVolumePhase函数更新状态设置 phase 为 available

if volume.Spec.ClaimRef == nil {

klog.V(4).Infof(“synchronizing PersistentVolume[%s]: volume is unused”, volume.Name)

if _, err := ctrl.updateVolumePhase(volume, v1.VolumeAvailable, “”); err != nil {

return err

}

return nil

} else /* pv.Spec.ClaimRef != nil */ {

//正在被bound中，更新状态available

if volume.Spec.ClaimRef.UID == “” {

klog.V(4).Infof(“synchronizing PersistentVolume[%s]: volume is pre-bound to claim %s”, volume.Name, claimrefToClaimKey(volume.Spec.ClaimRef))

if _, err := ctrl.updateVolumePhase(volume, v1.VolumeAvailable, “”); err != nil {

return err

}

return nil

}

klog.V(4).Infof(“synchronizing PersistentVolume[%s]: volume is bound to claim %s”, volume.Name, claimrefToClaimKey(volume.Spec.ClaimRef))

// Get the PVC by name

var claim *v1.PersistentVolumeClaim

//根据 pv 的 claimRef 获得 pvc

claimName := claimrefToClaimKey(volume.Spec.ClaimRef)

obj, found, err := ctrl.claims.GetByKey(claimName)

if err != nil {

return err

}

//如果在队列未发现，可能是volume被删除了，或者失败了，重新同步pvc

if !found && metav1.HasAnnotation(volume.ObjectMeta, pvutil.AnnBoundByController) {

if volume.Status.Phase != v1.VolumeReleased && volume.Status.Phase != v1.VolumeFailed {

obj, err = ctrl.claimLister.PersistentVolumeClaims(volume.Spec.ClaimRef.Namespace).Get(volume.Spec.ClaimRef.Name)

if err != nil && !apierrors.IsNotFound(err) {

return err

}

found = !apierrors.IsNotFound(err)

if !found {

obj, err = ctrl.kubeClient.CoreV1().PersistentVolumeClaims(volume.Spec.ClaimRef.Namespace).Get(context.TODO(), volume.Spec.ClaimRef.Name, metav1.GetOptions{})

if err != nil && !apierrors.IsNotFound(err) {

return err

}

found = !apierrors.IsNotFound(err)

}

}

}

if !found {

klog.V(4).Infof(“synchronizing PersistentVolume[%s]: claim %s not found”, volume.Name, claimrefToClaimKey(volume.Spec.ClaimRef))

} else {

var ok bool

claim, ok = obj.(*v1.PersistentVolumeClaim)

if !ok {

return fmt.Errorf(“Cannot convert object from volume cache to volume %q!?: %#v”, claim.Spec.VolumeName, obj)

}

klog.V(4).Infof(“synchronizing PersistentVolume[%s]: claim %s found: %s”, volume.Name, claimrefToClaimKey(volume.Spec.ClaimRef), getClaimStatusForLogging(claim))

}

if claim != nil && claim.UID != volume.Spec.ClaimRef.UID {

klog.V(4).Infof(“synchronizing PersistentVolume[%s]: claim %s has different UID, the old one must have been deleted”, volume.Name, claimrefToClaimKey(volume.Spec.ClaimRef))

// Treat the volume as bound to a missing claim.

claim = nil

}

//claim可能被删除了，或者pv被删除了

if claim == nil {

if volume.Status.Phase != v1.VolumeReleased && volume.Status.Phase != v1.VolumeFailed {

// Also, log this only once:

klog.V(2).Infof(“volume %q is released and reclaim policy %q will be executed”, volume.Name, volume.Spec.PersistentVolumeReclaimPolicy)

if volume, err = ctrl.updateVolumePhase(volume, v1.VolumeReleased, “”); err != nil {

return err

}

}

//根据persistentVolumeReclaimPolicy配置做相应的处理，Retain 保留/ Delete 删除/ Recycle 回收

if err = ctrl.reclaimVolume(volume); err != nil {

return err

}

if volume.Spec.PersistentVolumeReclaimPolicy == v1.PersistentVolumeReclaimRetain {

// volume is being retained, it references a claim that does not exist now.

klog.V(4).Infof(“PersistentVolume[%s] references a claim %q (%s) that is not found”, volume.Name, claimrefToClaimKey(volume.Spec.ClaimRef), volume.Spec.ClaimRef.UID)

}

return nil

} else if claim.Spec.VolumeName == “” {

if pvutil.CheckVolumeModeMismatches(&claim.Spec, &volume.Spec) {

volumeMsg := fmt.Sprintf(“Cannot bind PersistentVolume to requested PersistentVolumeClaim %q due to incompatible volumeMode.”, claim.Name)

ctrl.eventRecorder.Event(volume, v1.EventTypeWarning, events.VolumeMismatch, volumeMsg)

claimMsg := fmt.Sprintf(“Cannot bind PersistentVolume %q to requested PersistentVolumeClaim due to incompatible volumeMode.”, volume.Name)

ctrl.eventRecorder.Event(claim, v1.EventTypeWarning, events.VolumeMismatch, claimMsg)

// Skipping syncClaim

return nil

}

if metav1.HasAnnotation(volume.ObjectMeta, pvutil.AnnBoundByController) {

klog.V(4).Infof(“synchronizing PersistentVolume[%s]: volume not bound yet, waiting for syncClaim to fix it”, volume.Name)

} else {

klog.V(4).Infof(“synchronizing PersistentVolume[%s]: volume was bound and got unbound (by user?), waiting for syncClaim to fix it”, volume.Name)

}

ctrl.claimQueue.Add(claimToClaimKey(claim))

return nil

// 已经绑定更新状态status phase为Bound

} else if claim.Spec.VolumeName == volume.Name {

// Volume is bound to a claim properly, update status if necessary

klog.V(4).Infof(“synchronizing PersistentVolume[%s]: all is bound”, volume.Name)

if _, err = ctrl.updateVolumePhase(volume, v1.VolumeBound, “”); err != nil {

// Nothing was saved; we will fall back into the same

// condition in the next call to this method

return err

}

return nil

// PV绑定到PVC上，但是PVC被绑定到其他PV上，重置

} else {

// Volume is bound to a claim, but the claim is bound elsewhere

if metav1.HasAnnotation(volume.ObjectMeta, pvutil.AnnDynamicallyProvisioned) && volume.Spec.PersistentVolumeReclaimPolicy == v1.PersistentVolumeReclaimDelete {

if volume.Status.Phase != v1.VolumeReleased && volume.Status.Phase != v1.VolumeFailed {

klog.V(2).Infof(“dynamically volume %q is released and it will be deleted”, volume.Name)

if volume, err = ctrl.updateVolumePhase(volume, v1.VolumeReleased, “”); err != nil {

return err

}

}

if err = ctrl.reclaimVolume(volume); err != nil {

return err

}

return nil

} else {

if metav1.HasAnnotation(volume.ObjectMeta, pvutil.AnnBoundByController) {

klog.V(4).Infof(“synchronizing PersistentVolume[%s]: volume is bound by controller to a claim that is bound to another volume, unbinding”, volume.Name)

if err = ctrl.unbindVolume(volume); err != nil {

return err

}

return nil

} else {

klog.V(4).Infof(“synchronizing PersistentVolume[%s]: volume is bound by user to a claim that is bound to another volume, waiting for the claim to get unbound”, volume.Name)

if err = ctrl.unbindVolume(volume); err != nil {

return err

}

return nil

}

}

}

}

}

这个方法有点长，我们一步步分析：

这个方法首先会校验一个ClaimRef有没有被设置，因为如果一个PV被绑定了，那么它的ClaimRef属性是会被赋值的，我们可以使用kubectl edit pv mongodb-pv 进入到实例中查看当前的PV属性，会发现：

claimRef:

apiVersion: v1

kind: PersistentVolumeClaim

name: mongodb-pvc

namespace: default

resourceVersion: “824043”

uid: 5cf34ad0-2181-4d99-9875-0d4559e58f42

所以如果这个属性为空，那么需要更新PV的状态为Available。

如果ClaimRef不为空，接下来会校验UID属性，UID为空说明PV绑定了PVC，但是PVC却没有绑定PV，所以需要重新设置PV的状态为Available；

然后获取PV对应的PVC，如果在PVC集合里没有找到对应的PVC，那么为了防止本地缓存还未刷新，所以再通过apiserver再去找一下，然后给found变量打上标记；

如果找到了对应的PVC，那么需要比较一下UID是否相等，如果不相等，那么说明不是被绑定的那个PVC，可以认为PVC是被删除了，那么需要更新释放PV，将PV的状态改为Released；

然后会调用reclaimVolume方法，这个方法里面会根据persistentVolumeReclaimPolicy配置做相应的处理：

PersistentVolumeController#reclaimVolume

func (ctrl *PersistentVolumeController) reclaimVolume(volume *v1.PersistentVolume) error {

…

switch volume.Spec.PersistentVolumeReclaimPolicy {

//这个策略允许手动回收资源，当PVC被删除后，PV仍然可以存在，管理员可以手动的执行删除PV

case v1.PersistentVolumeReclaimRetain:

klog.V(4).Infof(“reclaimVolume[%s]: policy is Retain, nothing to do”, volume.Name)

//回收PV，如果没有pod在使用PV，那么将该PV的状态设置为Available

case v1.PersistentVolumeReclaimRecycle:

…

ctrl.scheduleOperation(opName, func() error {

ctrl.recycleVolumeOperation(volume)

return nil

})

//这个策略会在PVC被删除之后，连带将PV以及PV管理的存储资源也删除

case v1.PersistentVolumeReclaimDelete:

…

ctrl.scheduleOperation(opName, func() error {

_, err := ctrl.deleteVolumeOperation(volume)

if err != nil {

metrics.RecordMetric(volume.Name, &ctrl.operationTimestamps, err)

}

return err

})

default:

…

}

return nil

}

这个方法里面是用了一个switch case来处理PersistentVolumeReclaimPolicy策略，如果是Retain策略，那么需要手动执行删除，这里只记录了一个log；如果是Recycle则调用recycleVolumeOperation执行解绑操作；如果是Delete则调用deleteVolumeOperation方法将对应的PV删除。

下面我们来挑deleteVolumeOperation看一下这个方法的具体实现：

func (ctrl *PersistentVolumeController) deleteVolumeOperation(volume *v1.PersistentVolume) (string, error) {

klog.V(4).Infof(“deleteVolumeOperation [%s] started”, volume.Name)

//这里先读取最新的PV实例

newVolume, err := ctrl.kubeClient.CoreV1().PersistentVolumes().Get(context.TODO(), volume.Name, metav1.GetOptions{})

if err != nil {

klog.V(3).Infof(“error reading persistent volume %q: %v”, volume.Name, err)

return “”, nil

}

//如果已经被删除了，直接返回

if newVolume.GetDeletionTimestamp() != nil {

klog.V(3).Infof(“Volume %q is already being deleted”, volume.Name)

return “”, nil

}

//看一下是否还能找得到对应的PVC

needsReclaim, err := ctrl.isVolumeReleased(newVolume)

if err != nil {

klog.V(3).Infof(“error reading claim for volume %q: %v”, volume.Name, err)

return “”, nil

}

//如果还有PVC与之关联，那么就不能删除这个PV

if !needsReclaim {

klog.V(3).Infof(“volume %q no longer needs deletion, skipping”, volume.Name)

return “”, nil

}

//调用相应的plugin删除PV

pluginName, deleted, err := ctrl.doDeleteVolume(volume)

…

return pluginName, nil

}

可见在执行删除的时候先会进行一系列的校验，会去确认这个PV是否已手动删除、PV所对应的PVC是否还存在然后才调用对应的插件执行删除。

我们继续回到PersistentVolumeController的syncVolume方法中。对claim进行校验之后会继续检查VolumeName是否为空，这种情况是表明正在绑定中；

如果PVC的VolumeName等于PV的name，那么说明已经绑定，那么更新一下状态为Bound；否则表示PV绑定到PVC上，但是PVC被绑定到其他PV上，检查一下是否是dynamically provisioned自动生成的，如果是的话就释放这个PV；如果是手动创建的PV，那么调用unbindVolume进行解绑。

到这里我们volumeWorker已经看完了，接下来看一下claimWorker

claimWorker

和volumeWorker一样，claimWorker也在一个循环里不断的获取PVC，然后调用updateClaim方法进入到syncClaim进行具体的操作：

PersistentVolumeController#syncClaim

func (ctrl *PersistentVolumeController) syncClaim(claim *v1.PersistentVolumeClaim) error {

klog.V(4).Infof(“synchronizing PersistentVolumeClaim[%s]: %s”, claimToClaimKey(claim), getClaimStatusForLogging(claim))

newClaim, err := ctrl.updateClaimMigrationAnnotations(claim)

if err != nil {

return err

}

claim = newClaim

//根据当前对象中的注解决定调用逻辑

if !metav1.HasAnnotation(claim.ObjectMeta, pvutil.AnnBindCompleted) {

//处理未绑定的pvc

return ctrl.syncUnboundClaim(claim)

} else {

//处理已经绑定的pvc

return ctrl.syncBoundClaim(claim)

}

}

这个方法会从缓存里面重新获取一些PVC，然后根据PVC的注解决定调用逻辑。

下面我先从syncUnboundClaim开始，方法比较长，分成两部分：

func (ctrl *PersistentVolumeController) syncUnboundClaim(claim *v1.PersistentVolumeClaim) error {

//说明pvc处于pending状态，没有完成绑定操作

if claim.Spec.VolumeName == “” {

// User did not care which PV they get.

// 是否是延迟绑定

delayBinding, err := pvutil.IsDelayBindingMode(claim, ctrl.classLister)

if err != nil {

return err

}

// [Unit test set 1]

//根据声明的PVC设置的字段找到对应的PV

volume, err := ctrl.volumes.findBestMatchForClaim(claim, delayBinding)

if err != nil {

klog.V(2).Infof(“synchronizing unbound PersistentVolumeClaim[%s]: Error finding PV for claim: %v”, claimToClaimKey(claim), err)

return fmt.Errorf(“Error finding PV for claim %q: %v”, claimToClaimKey(claim), err)

}

//如果没有可用volume情况

if volume == nil {

klog.V(4).Infof(“synchronizing unbound PersistentVolumeClaim[%s]: no volume found”, claimToClaimKey(claim))

switch {

case delayBinding && !pvutil.IsDelayBindingProvisioning(claim):

if err = ctrl.emitEventForUnboundDelayBindingClaim(claim); err != nil {

return err

}

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

本次面试答案，以及收集到的大厂必问面试题分享：

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
h {

case delayBinding && !pvutil.IsDelayBindingProvisioning(claim):

if err = ctrl.emitEventForUnboundDelayBindingClaim(claim); err != nil {

return err

}

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。[外链图片转存中…(img-bDbkyRXw-1713746666322)]

[外链图片转存中…(img-dwqxPUXa-1713746666323)]

[外链图片转存中…(img-Tze8Ft6E-1713746666323)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

本次面试答案，以及收集到的大厂必问面试题分享：

[外链图片转存中…(img-Kp2TysnS-1713746666323)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！