当前位置:网站首页 > R语言数据分析 > 正文

spring教程视频推荐(spring教程 csdn)



转载:https://blog.csdn.net/_/article/details/

代码仓库地址:https://gitee.com/CandyWall/spring-source-study
跟着黑马满一航老师的spring高级49讲做的学习笔记,本笔记跟视频内容的项目名称和代码略有不同,我将49讲的代码每一讲的代码都拆成了独立的springboot项目,并且项目名称尽量做到了见名知意,都是基于我自己的考量,代码都已经过运行验证过的,仅供参考。

视频教程地址:https://www.bilibili.com/video/BV1P44y1N7QG

注:

  1. 每一讲对应一个二级标题,每一个三级标题是使用子项目名称命名的,和我代码仓库的项目是一一对应的;
    ​ 2. 代码里面用到了lombok插件来简化了Bean中的get()、set()方法,以及日志的记录的时候用了lombok的@Slf4j注解。

笔记中如有不正确的地方,欢迎在评论区指正,非常感谢!!!

每个子项目对应的视频链接以及一些重要内容的笔记

spring_01_beanfactory_applicationcontext_differences_connections

p1 000-Spring高级49讲-导学

p2 001-第一讲-BeanFactory与ApplicationContext_1

测试代码:

 
  

到底什么是

  • 它是的父接口

    鼠标选中,按或者打开类图,可以看到的有个父接口是

    image-20220323144102451

  • 它才是 的核心容器,主要的 实现都 [组合]了他的功能

    打印,可以看到SpringBoot的启动程序返回的的具体的实现类是

     

    按图索骥,又间接继承了,在这个类里面可以找到作为成员变量出现。

    image-20220404140925587

    image-20220404141152288

p3 002-第一讲-BeanFactory功能

接口中的方法

image-20220323145908937

查看默认的类中的的实际类型

 
  

从打印结果可以了解到实际类型为,所以这里以的一个实现类作为出发点,进行分析。

它的类图如下:

image-20220323150712761

这里我们暂且不细看,先看的父类,先选中它,然后按,可以跳转到对应的源码,可以看到有个私有的成员变量

image-20220323150929451

这里通过反射的方法来获取该成员变量,进行分析

先补充一下反射获取某个类的成员变量的步骤:

获取成员变量,步骤如下:

  1. 获取Class对象
  2. 获取构造方法
  3. 通过构造方法,创建对象
  4. 获取指定的成员变量(私有成员变量,通过setAccessible(boolean flag)方法暴力访问)
  5. 通过方法,给指定对象的指定成员变量赋值或者获取值

public void set(Object obj, Object value)

在指定对象obj中,将此 Field 对象表示的成员变量设置为指定的新值

public Object get(Object obj)

返回指定对象obj中,此 Field 对象表示的成员变量的值

代码如下:

 
  

这里为什么要传一个的变量进去呢?打印了这个的实际类型为,查看其类图,可以了解到该类也实现了接口,所以这里反射获取某个类的成员变量的方法中可以作为参数传进来。

image-20220324003636506

p4 003-第一讲-ApplicationContext功能1

比 多点啥?

多实现了四个接口:

  • : 国际化功能,支持多种语言
  • : 通配符匹配资源路径
  • : 环境信息,系统环境变量,、等配置文件中的值
  • : 发布事件对象

image-20220324115647260

  1. 在目录下创建四个文件、、、,然后分别在四个文件里面定义同名的,比如在中定义,在中定义,在中定义,这样在代码中就可以根据这个和不同的语言类型获取不同的了。

     

    运行结果如下:

    image-20220324181409040

p5 004-第一讲-ApplicationContext功能2,3

  1. 例1:获取类路径下的开头的配置文件

     

    image-20220324182456169

    例2:获取相关包中的配置文件

     

    image-20220324183236048

  2. 获取系统环境变量中的和项目的中的属性

     

    image-20220324191740825

p6 005-第一讲-ApplicationContext功能4

  1. 定义一个用户注册事件类,继承自类

     

    再定义一个监听器类,用于监听用户注册事件,类头上需要加注解,将该类交给管理,定义一个处理事件的方法,参数类型为用户注册事件类的对象,方法头上需要加上注解

     

    接着再定义一个用户服务类,里面有个方法可以完成用户的注册,注册完毕后发布一下用户注册完毕事件

     

    最后在启动类中调用一下里面的方法注册一个新用户,中就能处理这个用户注册完毕的事件,实现了类和类的解耦。

     

    image-20220324210306704

p7 006-第一讲-小结

spring_02_01_beanfactory_impl

p8 007-第二讲-BeanFactory实现

p9 008-第二讲-BeanFactory实现

p10 009-第二讲-BeanFactory实现-后处理器排序

 
  

接着第一讲中的内容,执行以下代码,可以了解到

 
  

类内部组合的实际类型为,底层创建实体类就是依赖于这个类,所以它是接口最重要的一个实现类,下面使用这个类,模拟一下使用类创建其他实体类对象的过程。

测试代码如下:

 
  

总结:

  • beanFactory 不会做的事
    • 不会主动调用BeanFactory的后处理器
    • 不会主动添加Bean的后处理器
    • 不会主动初始化单例
    • 不会解析BeanFactory,还不会解析 ${}, #{}
  • Bean后处理器会有排序的逻辑

    先定义一个接口Inter,再定义两个Bean,名称分别为Bean3和Bean4,都继承Inter,接着在Config中通过@Bean注解将Bean3和Bean4都加进Bean工厂中,然后在Bean1中定义一个Inter对象,通过@Autowired注解将实现类注入进来。

     

    如果把以接口声明的变量名定义为,注解首先会根据名称(byName)进行匹配,没有匹配上,于是又会根据类型(byType)进行匹配,发现Bean3和Bean4都实现了Inter接口,会报无法自动装配的错误。

    image-20220325121422536

    所以为了避免这种错误,以接口声明的变量名只能为或者,这里把以接口声明的变量名定义为,然后就不报错了,会通过的方式进行匹配。

    image-20220325121717437

    在main方法中去获取Inter,然后打印,可以看到注入的是Bean3

    image-20220325133334762

    如果此时在上面再加上注解,然后再打印结果,结果还是,为什么呢?我们先看一下加入的Bean后处理器的顺序,解析注解的后处理器的顺序排在解析注解的后处理器的前面,所以会被先启用,故注解先被解析了。

    image-20220325134154838

    如果想要让注解先被解析呢,这就需要让后处理器比先加入,代码如下:

     

    这样一来注入的结果就是,注解被先解析了

    image-20220325141300707

    通过给添加一些后处理的时候会默认设置比较器,可以对进行排序,排序的依据是内部的属性,其中的order属性的值为,的属性的值为。

    image-20220325143844005

    从打印结果来看,,,的值更小,所以排序的时候会排在前面

    image-20220325144433436

  • 本身功能只是将定义好的加进来,而的后处理器补充了一些的定义,可以解析、等注解,将这些被注解修饰的也加进。和注解的解析过程的源码可以看和

    image-20220325005027558

    image-20220325005135527

  • 要想、等注解被解析,还要添加的后处理器,可以针对的生命周期的各个阶段提供扩展。
  • BeanFactory中的对象都是懒加载的,如果不去调用get()方法获取的话,就不会初始化,如果想要让对象在get()之前就创建好,需要调用方法。
  • 教程弹幕中有人问:为啥和注解不需要建立联系就能使用?
    • 建立联系了啊,上面也获取了的后置处理器,然后循环就是建立的后置处理器和BeanFactory的联系。
    • 另外加不加,类中的n注解都会被解析,是用于类扫描的时候用的,加了这个注解的类被扫描到了就会被放进工厂

spring_02_02_applicationcontext_impl

p11 010-第二讲-ApplicationContext实现1,2

p12 011-第二讲-ApplicationContext实现3

p13 012-第二讲-ApplicationContext实现4

四个重要的接口的实现类

image-20220325174005606

  • :
  • :
  • :
  • :

相关测试代码如下:

 
  

如下:

 
  

spring_03_bean_lifecycle

p14 013-第三讲-bean生命周期

项目启动类

 
  

定义一个,加上注解,再编写一些方法,给这些方法加上的生命周期过程中的注解

 
  

编写自定义的后处理器,需要实现和接口,并加上注解,对的生命周期过程进行扩展。

 
  

运行结果如下:

image-20220326140553213

p15 014-第三讲-模板方法

 
  

spring_04_beanpostprocessor

p16 015-第四讲-常见bean后处理器1,2

p17 016-第四讲-常见bean后处理器3

定义三个,名称分别为,,,其中中依赖了和,通过的注解注入,通过注解注入,再通过注解注入一个的环境变量的值。最后定义两个方法和,分别加上和注解。

 
  

这里用 来探究一下、、、、以及项目中的这些注解分别是由哪个后处理器来解析的。

注: 是一个【干净】的容器,默认不会添加任何后处理器,方便做测试,这里用也可以完成测试,只是会比使用麻烦一些。

测试代码如下:

 
  

运行结果如下:

image-20220327233426083

经过测试和运行结果的比对:

  • 注解对应的后处理器是;
  • 注解需要配合注解一起使用,所以也用到了后处理器,然后注解还需要再用到解析器,否则会报错;
  • 、、注解对应的后处理器是;
  • 注解对应的后处理器是。

p18 017-第四讲-@Autowired bean后处理器执行分析

p19 018-第四讲-@Autowired bean后处理器执行分析

本案例测试代码紧接着上面,这里对中加了注解的属性注入、方法注入以及方法注入环境变量的过程进行分析。

 
  
  • 这个后处理器就是通过调用完成注解的解析和注入的功能
  • 这个方法中又调用了一个私有的方法,其返回值中封装了被注解修饰的属性和方法
  • 然后会调用进行依赖注入
  • 由于的源码调用链过长,摘出主要调用过程进行说明:
  • 成员变量注入,
     

    注入

     

    的过程:

    • 会把中加了注解的属性的先拿到,这里拿到的就是 ,然后再通过反射拿到这个属性,
    • 将这个属性封装成一个对象,再去调用拿到
    • 最后把值赋给这个属性
  • 方法参数注入,
     

    注入

     

    的过程:

    • 会把中加了注解的方法的先拿到,这里拿到的就是 ,然后再通过反射拿到这个方法,
    • 将这个属性封装成一个对象,再去调用拿到
    • 最后调用方法,给方法参数赋值。
  • 方法参数注入,参数类型为String类型,且加上了@Value注解,
     

    注入环境变量

     

    的过程:

    • 会把中加了注解的方法的先拿到,这里拿到的就是 ,然后再通过反射拿到这个方法,
    • 将这个属性封装成一个对象,再去调用拿到
    • 最后调用方法,给方法参数赋值。

全部测试代码如下:

 
  

运行结果如下:

image-20220329115607946

spring_05_beanfactorypostprocessor

p20 019-第五讲-常见工厂后处理器

定义、、、、 5个类,其中上面加上和注解,上加注解,中通过注解定义,、上加注解,类的定义参考下图,由于涉及的类比较多,具体代码可以去我的代码仓库获取。

image-20220329142407664

这里用 来探究一下、、、这些注解分别是由哪个后处理器来解析的。

测试代码如下:

 
  

经过测试和运行结果的比对:

  • 、对应的工厂后处理器是;
  • 对应的工厂后处理器是。

p21 020-第五讲-工厂后处理器模拟实现-组件扫描

p22 021-第五讲-工厂后处理器模拟实现-组件扫描

自定义组件扫描工厂后处理器来解析注解,代码如下:

 
  

测试代码:

 
  

运行结果:

image-20220329192201153

p23 022-第五讲-工厂后处理器模拟实现-@Bean

自定义工厂后处理器来解析注解,代码如下:

 
  

注:自定义解析 和 后面的 注解的工厂后处理器,实现接口而不是接口,这么做的原因是:

  • 实现,方法,参数工厂调用不了方法,需要做强制转换,转成类型,才能调用方法。
  • 实现,它里面除了方法,还有一个,参数可以直接调用方法,避免了向的强制转换。

测试代码:

 
  

运行结果:

image-20220329224604315

p25 024-第五讲-工厂后处理器模拟实现-Mapper

自定义工厂后处理器来解析注解,代码如下:

 
  

测试代码:

 
  

运行结果:

image-20220330012845575

spring_06_aware_initializingbean

p26 025-第六讲-Aware与InitializingBean接口

接口用于注入一些与容器相关信息,例如:

a. 注入 的名字

b. 注入 容器

c. 注入 容器

d. 注入 解析器,解析

定义一个类,实现、和接口并实现其方法,再定义两个方法,其中一个加@Autowired注解,注入ApplicationContext容器,另一个加@PostConstruct注解,具体代码如下:

 
  

测试代码:

 
  

运行结果:

image-20220330173209568

加了和注解的方法并没有被执行,而和接口方法都被执行了。

修改测试代码,把解析和注解的后处理加进来,然后再运行一下

 
  

运行结果:

image-20220330173807848

可以看到这下都执行了

有人可能会问:、、的功能用 注解就能实现啊,为啥还要用 接口呢?
接口可以用 注解实现,为啥还要用呢?
简单地说:

  • 和注解的解析需要用到 后处理器,属于扩展功能,而 接口属于内置功能,不加任何扩展,就能识别;
  • 某些情况下,扩展功能会失效,而内置功能不会失效

    p27 026-第六讲-@Autowired失效分析

    • 例1:比如没有把解析和注解的的后处理器加到工厂中,你会发现用 注入 成功, 而 注入 失败
    • 例2:定义两个类(类上加注解),名字分别叫和,都实现注入容器和初始化功能,用和注解实现,用实现和接口的方式实现,另外,两个类中都通过注解的方式注入一个,代码如下:

      :

       

      测试代码:

       

      运行结果:

      image-20220331090139965

      :

       

      测试代码:

       

      运行结果:

      image-20220331090537999

      Java配置类在添加了 工厂后处理器后,你会发现用传统接口方式的注入和初始化依然成功,而 和 的注入和初始化失败。

      那是什么原因导致的呢?

      配置类 注解失效分析

      • Java 配置类不包含 的情况

        ApplicationContextBeanFactoryPostProcessorBeanPostProcessorJava配置类1. 执行 BeanFactoryPostProcessor2. 注册 BeanPostProcessor3. 创建和初始化3.1 依赖注入扩展(如 @Value 和 @Autowired)3.2 初始化扩展(如 @PostConstruct)3.3 执行 Aware 及 InitializingBean3.4 创建成功ApplicationContextBeanFactoryPostProcessorBeanPostProcessorJava配置类

      • 配置类包含 的情况

        根据上面的时序图可以得知,正常情况下,会在配置类初始化之前执行,而Java配置类里面却定义了一个,要创建其中的 ,必须提前创建 配置类,这样就会在Java配置类初始化后执行了,而此时的 还未准备好,导致 等注解失效。

        ApplicationContextBeanFactoryPostProcessorBeanPostProcessorJava配置类3. 创建和初始化3.1 执行 Aware 及 InitializingBean3.2 创建成功1. 执行 BeanFactoryPostProcessor2. 注册 BeanPostProcessorApplicationContextBeanFactoryPostProcessorBeanPostProcessorJava配置类

总结:

  • 接口提供了一种【内置】 的注入手段,可以注入 ,;
  • 接口提供了一种 【内置】 的初始化手段;
  • 内置的注入和初始化不收扩展功能的影响,总会被执行,因此 框架内部的类常用它们。

spring_07_init_destroy

p28 027-第七讲-初始化与销毁

定义类,实现接口和对应的接口方法,再定义方法,在方法上加注解,最后定义

 
  

定义类,实现接口和对应的接口方法,再定义方法,在方法上加注解,最后定义

 
  

定义类,类上加注解,类中通过注解把和加到工厂中,分别在注解中指定,

 
  

编写测试代码,观察三个初始化方法和三个销毁方法的执行顺序

 
  

运行结果:

image-20220401013108042

可以看到,spring提供了多种初始化和销毁手段

  • 对于,三个初始化方法的执行顺序是

    -> 接口 -> 的

  • 对于, 三个销毁方法的执行顺序是

    -> 接口 -> 的

spring_08_scope

p29 028-第八讲-Scope

的类型:

  • :单例
  • :多例
  • :请求
  • :的会话
  • :的

测试类型中的、、

定义类,加上和注解,指定类型为,在类型中定义方法,方法上加注解,代码如下:

 
  

定义类,加上和注解,指定类型为,在类型中定义方法,方法上加注解,代码如下:

 
  

定义类,加上和注解,指定类型为,在类型中定义方法,方法上加注解,代码如下:

 
  

编写一个类,加上注解,在该类中通过注解注入、和的实例,需要注意,这里还需要加注解(至于原因后面会解释),否则会导致域失效,再定义一个方法,加上注解,用于响应一个请求,在方法中,打印、和,代码如下:

 
  

启动类

 
  

启动后,用谷歌浏览器访问 http://localhost:8080/test,

浏览器运行结果如下:

image-20220401222141258

再刷新一下当前页,查看运行结果:

image-20220401222154488

控制台运行结果如下:

image-20220401214139467

可以看到两次刷新只有对象发生了改变,这是由于为类型的对象,会在请求结束后销毁,再来一次请求就会重新创建,请求结束后又会销毁。

接下来我们换个浏览器访问 http://localhost:8080/test,对比两个浏览器的显示结果:

image-20220401222256653

黑马程序员spring2016springday01上课笔记doc img 0星 超过10%的资源 541KBimg下载

可以看到这回除了对象不同,对象也不同了,这是因为开一个新的浏览器会创建一个新的会话,所以对象也不同了。

继续进行测试,在配置一个属性,这个属性的默认值为分钟,这样没有操作浏览器的话就会销毁对应,不过经过测试这个这个属性最少为分钟,低于1分钟一律按照1分钟算。具体原理看这篇博客:https://www.jianshu.com/p/9d91cca74082,里面进行了源码级别的分析。

设置好之后,重启项目, 然后去浏览器访问,1分钟后控制台会打印被销毁,如下图所示:

image-20220402144856449

那什么时候为的对象会销毁呢?按理说应该是在程序结束,也即内置的服务器停止的时候调用,但是经过测试:无论是在控制台停止项目,还是调用的方法,都没有调用的销毁方法,有知道什么方法可以让它调用的,请评论区告知,谢谢!!!

p30 029-第八讲-Scope失效解决1,2

p31 030-第八讲-Scope失效解决3,4

定义1个单例类,指定它的为,定义个多例类,、、、、,将这个多例类的对象注入到的个属性中,其中用来演示多例对象注入到单例对象中失效的情况,其他四个类的对象用来演示四种解决失效的方法。相关类的定义如下:

 
  

测试代码:

 
  

运行结果如下:

image-20220406141812580

是框架中非常重要的功能,其主要实现通常情况下是动态代理,但是这个说法并不全面,还有另外两种实现:

  • 编译器
  • 类加载

spring_09_aop_ajc

p32 031-第九讲-aop之ajc增强

先看的第一种实现编译器代码增强,这是一种编译时的代码增强。

新建一个普通的maven项目

  • 添加依赖

    使用编译器进行代码增强,首先需要在文件中加入编译器插件依赖

     

    加入的依赖

     

    加入日志和单元测试的依赖

     
  • 需要增强的类
     
  • 切面类,编写表达式,对类的方法进行增强
     
  • 测试代码
     
  • 编译项目,这里需要使用来编译,打开中的面板,点击

    image-20220410183011468

    然后再运行测试代码,可以看到创建对象并调用方法会先执行切面类中的方法

    image-20220410183108780

    注:

    • 有些小伙伴可能会遇到问题:明明按照一样的步骤来操作,可是运行以后代码并没有增强。这是由于中在执行代码之前会默认编译一遍代码,这本来是正常的,可是,如果使用来编译代码,会在执行代码前将编译的代码覆盖,这就会导致的编译器增强的代码被覆盖,所以会看不到最终的运行效果。
    • 解决办法:在设置中将自动构建项目的选项勾上,就不会出现多次编译覆盖的问题了。

      image-20220410183955137

总结:

  • 可以看到没有引入任何跟框架相关的包,类是通过直接的方式获得的,所以也就不存在使用了动态代理的说法了
  • 打开编译后的文件,双击以后idea会反编译该字节码文件,可以看到方法体的开头加了一行代码,这就是增强的代码,这是编译器在编译类的时候为我们添加的代码,这是一种编译时的增强。

    image-20220410184651224

spring_10_aop_agent

p33 032-第十讲-aop之agent增强

现在来看的另外一种实现增强,这是一种类加载时的代码增强。

  • 新建一个普通的maven项目
    • 加入的依赖
       

      加入日志和单元测试的依赖

       
    • 需要增强的类
       
    • 切面类,编写表达式,对类的方法进行增强
       
    • 测试代码
       

      运行时需要在 VM options 里加入 把其中 改为你自己 仓库起始地址

      image-20220410210057854

      注:还需要在目录下建一个配置文件,内容如下,会自动扫描到这个配置文件,不加这个配置文件不会出效果。

      image-20220410210354881

       

      运行测试代码,可以看到创建对象并调用方法会先执行切面类中的方法

      image-20220410210458098

      注:

      • 有些小伙伴可能会遇到问题:明明按照一样的步骤来操作,可是运行以后代码并没有增强。这是由于中在执行代码之前会默认编译一遍代码,这本来是正常的,可是,如果使用来编译代码,会在执行代码前将编译的代码覆盖,这就会导致的编译器增强的代码被覆盖,所以会看不到最终的运行效果。
      • 解决办法:在设置中将自动构建项目的选项勾上,就不会出现多次编译覆盖的问题了。

        image-20220410183955137

    总结:

    • 可以看到没有引入任何跟框架相关的包,类是通过直接的方式获得的,所以也就不存在使用了动态代理的说法了
    • 打开编译后的文件,双击以后idea会反编译该字节码文件,可以看到方法体中并没有添加多余的代码,所以就不是编译时增强了,而是类加载的时候增强的,这里可以借助阿里巴巴的Arthas工具,下载地址:https://arthas.aliyun.com/doc/en/download.html,解压以后进入到arthas的bin目录下,启动黑窗口,输入,在输出的进程列表里面找到我们要连接的进程,输入对应进程的序号,我这里是,连接上以后会打印的

      image-20220410235629087

      再输入反编译内存中的类

      image-20220410235616607

      可以看到和方法体的第一行都加了一行代码,这就说明通过添加虚拟机参数的方式可以在类加载的时候对代码进行增强。

spring_11_aop_proxy_jdk_cglib

p34 033-第十一讲-aop之proxy增强-jdk

测试代码

 
  

运行结果

image-20220411083443041

动态代理总结:

  1. 代理对象和目标对象是兄弟关系,都实现了接口,代理对象类型不能强转成目标对象类型;
  2. 目标类定义的时候可以加修饰。

p35 034-第十一讲-aop之proxy增强-cglib

 
  

运行结果

image-20220411085629883

动态代理总结:

  1. 的方法的第2个参数是,可以通过反射对目标方法进行调用
     
  2. 第4个参数,可以不用反射就能对目标方法进行调用;
     
  3. 代理类不需要实现接口;
  4. 代理对象和目标对象是父子关系,代理类继承于目标类;
  5. 目标类定义的时候不能加修饰,否则代理类就无法继承目标类了,会报异常;
  6. 目标类方法定义的时候不能加修饰,否则代理类继承目标类以后就不能重写目标类的方法了。

spring_12_aop_proxy_jdk_cglib_principle

p36 035-第十二讲-jdk代理原理

p37 036-第十二讲-jdk代理原理

p38 037-第十二讲-jdk代理源码

为了更好地探究动态代理原理,先用代码显式地模拟一下这个过程。

先定义一个接口,里面有一个方法,再定义一个类来实现这个接口,代码如下所示:

 
  

接下来对类中的方法进行增强

  1. 首先想到的是,再定义一个类也同样地实现一下接口,然后在方法中编写增强代码,接着再一个对象,调用它的方法,代码如下所示:
     
  2. 上面的代码把功能增强的代码和调用目标的代码都固定在了代理类的内部,不太灵活。因此可以通过定义一个接口的方式来将这部分代码解耦出来,代码如下:
     
  3. 第2个版本的代码虽然将功能增强的代码和调用目标的代码通过接口的方式独立出来了,但还是有问题,如果此时接口中新增了一个方法,类和类中都要实现方法,那么调用的和方法都将间接调用目标对象的方法,因为在的方法中调用的是方法,代码如下:
     

    改进方法是,代理类中调用方法的时候,通过反射把接口中对应的方法对象作为参数传给,代码如下:

     
  4. 第3个版本的代码其实已经离jdk动态代理生成的代码很相近了,为了更好地学习底层,更近一步,修改接口的中方法,使其具有类型的返回值,因此的方法也得有返回值,同时将代理对象本身作为第一个参数,具体代码如下:
     
  5. 到这里跟jdk的动态代理只有些微差距了,的动态代码会让代理类再继承一个类,里面定义了一个接口的对象,代理类中会通过调用父类Proxy的构造,这里建议结合视频教程理解。

p39 038-第十二讲-jdk代理字节码生成

p40 039-第十二讲-jdk反射优化

p41 040-第十三讲-cglib代理原理

p42 041-第十三讲-cglib代理原理-MethodProxy

p43 042-第十四讲-MethodProxy原理

p44 043-第十四讲-MethodProxy原理

p45 044-第十五讲-Spring选择代理

p46 045-第十五讲-Spring选择代理

p47 046-第十五讲-Spring选择代理

p48 047-第十六讲-切点匹配

p49 048-第十六讲-切点匹配

p50 049-第十七讲-Advisor与@Aspect

p51 050-第十七讲-findEligibleAdvisors

p52 051-第十七讲-wrapIfNecessary

p53 052-第十七讲-代理创建时机

p54 053-第十七讲-吐槽@Order

p55 054-第十七讲-高级切面转低级切面

p56 055-第十八讲-统一转换为环绕通知

p57 056-第十八讲-统一转换为环绕通知

p58 057-第十八讲-适配器模式

p59 058-第十八讲-调用链执行

p60 059-第十八讲-模拟实现调用链

p61 060-第十八讲-模拟实现调用链-责任链模式

p62 061-第十九讲-动态通知调用

p63 062-第十九讲-动态通知调用

p64 063-第廿讲-DispatcherServlet初始化时机

p65 064-第廿讲-DispatcherServlet初始化时机

p66 065-第廿讲-DispatcherServlet初始化执行的操作

p67 066-第廿讲-RequestMappingHandlerMapping

p68 067-第廿讲-RequestMappingHandlerAdapter

p69 068-第廿讲-RequestMappingHandlerAdapter-参数和返回值解析器

p70 069-第廿讲-RequestMappingHandlerAdapter-自定义参数解析器

p71 070-第廿讲-RequestMappingHandlerAdapter-自定义返回值解析器

p72 071-第廿一讲-参数解析器-准备

p73 072-第廿一讲-参数解析器-准备

p74 073-第廿一讲-参数解析器-@RequestParam 0-4

黑马程序员_超全面的JavaWeb教程-视频+源码笔记txt img 0星 超过10%的资源 76.0Bimg下载

p75 074-第廿一讲-参数解析器-组合模式

p76 075-第廿一讲-参数解析器 5-9

p77 076-第廿一讲-参数解析器 10-12

p78 077-第廿二讲-获取参数名

p79 078-第廿二讲-获取参数名

p80 079-第廿三讲-两套底层转换接口

p81 080-第廿三讲-一套高层转换接口

p82 081-第廿三讲-类型转换与数据绑定演示

p83 082-第廿三讲-web环境下数据绑定演示

p84 083-第廿三讲-绑定器工厂

p85 084-第廿三讲-绑定器工厂-@InitBinder扩展

p86 085-第廿三讲-绑定器工厂-ConversionService扩展

p87 086-第廿三讲-绑定器工厂-默认ConversionService

p88 087-第廿三讲-加餐-如何获取泛型参数

p89 088-第廿四讲-@ControllerAdvice-@InitBinder

p90 089-第廿四讲-@ControllerAdvice-@InitBinder

p91 090-第廿五讲-控制器方法执行流程

p92 091-第廿五讲-控制器方法执行流程

p93 092-第廿五讲-控制器方法执行流程-代码

p94 093-第廿六讲-@ControllerAdvice-@ModelAttribute

p95 094-第廿七讲-返回值处理器

p96 095-第廿七讲-返回值处理器-1

p97 096-第廿七讲-返回值处理器-2-4

p98 097-第廿七讲-返回值处理器-5-7

p99 098-第廿八讲-MessageConverter

p100 099-第廿八讲-MessageConverter

p101 100-第廿九讲-@ControllerAdvice-ResponseBodyAdvice

p102 101-第廿九讲-@ControllerAdvice-ResponseBodyAdvice

p103 102-第卅讲-异常处理

p104 103-第卅讲-异常处理

p105 104-第卅一讲-@ControllerAdvice-@ExceptionHandler

p106 105-第卅二讲-tomcat异常处理

p107 106-第卅二讲-tomcat异常处理-自定义错误地址

p108 107-第卅二讲-tomcat异常处理-BasicErrorController

p109 108-第卅二讲-tomcat异常处理-BasicErrorController

p110 109-第卅三讲-HandlerMapping与HandlerAdapter-1

p111 110-第卅三讲-HandlerMapping与HandlerAdapter-自定义

p112 111-第卅四讲-HandlerMapping与HandlerAdapter-2

p113 112-第卅五讲-HandlerMapping与HandlerAdapter-3

p114 113-第卅五讲-HandlerMapping与HandlerAdapter-3-优化

p115 114-第卅五讲-HandlerMapping与HandlerAdapter-3-优化

p116 115-第卅五讲-HandlerMapping与HandlerAdapter-4-欢迎页

p117 116-第卅五讲-HandlerMapping与HandlerAdapter-总结

p118 117-第卅六讲-MVC执行流程

p119 118-第卅六讲-MVC执行流程

p120 119-第卅七讲-构建boot骨架项目

p121 120-第卅八讲-构建boot war项目

p122 121-第卅八讲-构建boot war项目-用外置tomcat测试

p123 122-第卅八讲-构建boot war项目-用内嵌tomcat测试

p124 123-第卅九讲-boot执行流程-构造

p125 124-第卅九讲-boot执行流程-构造-1

p126 125-第卅九讲-boot执行流程-构造-2

p127 126-第卅九讲-boot执行流程-构造-3

p128 127-第卅九讲-boot执行流程-构造-4-5

p129 128-第卅九讲-boot执行流程-run-1

p130 129-第卅九讲-boot执行流程-run-1

p131 130-第卅九讲-boot执行流程-run-8-11

p132 131-第卅九讲-boot执行流程-run-2,12

p133 132-第卅九讲-boot执行流程-run-3

p134 133-第卅九讲-boot执行流程-run-4

p135 134-第卅九讲-boot执行流程-run-5

p136 135-第卅九讲-boot执行流程-run-5

p137 136-第卅九讲-boot执行流程-run-6

p138 137-第卅九讲-boot执行流程-run-7

p139 138-第卅九讲-boot执行流程-小结

p140 139-第卌讲-Tomcat重要组件

p141 140-第卌讲-内嵌Tomcat

p142 141-第卌讲-内嵌Tomcat与Spring整合

p143 142-第卌一讲-自动配置类原理

p144 143-第卌一讲-自动配置类原理

p145 144-第卌一讲-AopAutoConfiguration

p146 145-第卌一讲-AopAutoConfiguration

p147 146-第卌一讲-自动配置类2-4概述

p148 147-第卌一讲-自动配置类2-DataSource

p149 148-第卌一讲-自动配置类3-MyBatis

p150 149-第卌一讲-自动配置类3-mapper扫描

p151 150-第卌一讲-自动配置类4-事务

p152 151-第卌一讲-自动配置类5-MVC

p153 152-第卌一讲-自定义自动配置类

p154 153-第卌二讲-条件装配底层1

p155 154-第卌二讲-条件装配底层2

p156 155-第卌三讲-FactoryBean

p157 156-第卌四讲-@Indexed

p158 157-第卌五讲-Spring代理的特点

p159 158-第卌五讲-Spring代理的特点

p160 159-第卌六讲-@Value注入底层1

p161 160-第卌六讲-@Value注入底层2

p162 161-第卌七讲-@Autowired注入底层-doResolveDependency外1

p163 162-第卌七讲-@Autowired注入底层-doResolveDependency外2

p164 163-第卌七讲-@Autowired注入底层-doResolveDependency内1

p165 164-第卌七讲-@Autowired注入底层-doResolveDependency内2

p166 165-第卌七讲-@Autowired注入底层-doResolveDependency内3

p167 166-第卌七讲-@Autowired注入底层-doResolveDependency内4

p168 167-第卌八讲-事件监听器1

p169 168-第卌八讲-事件监听器2

p170 169-第卌八讲-事件监听器3

p171 170-第卌八讲-事件监听器4

p172 171-第卌八讲-事件监听器5

p173 172-第卌九讲-事件发布器1

p174 173-第卌九讲-事件发布器2

到此这篇spring教程视频推荐(spring教程 csdn)的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章,希望大家都能在编程的领域有一番成就!

版权声明


相关文章:

  • pilow和pillow区别(pillow和bolster 区别)2026-01-31 10:00:10
  • xavier名字(xavier名字来历)2026-01-31 10:00:10
  • treedms破解版(treesoft破解版)2026-01-31 10:00:10
  • spring教程网站(spring官方教程)2026-01-31 10:00:10
  • cvpr和iccv哪个好(cvpr和cvpr workshop)2026-01-31 10:00:10
  • grid布局高度(grid 布局)2026-01-31 10:00:10
  • cmake 多项目(cmake externalproject_add)2026-01-31 10:00:10
  • chrony服务器配置allow(chrony服务器配置)2026-01-31 10:00:10
  • redhat证书难考吗(red hat证书)2026-01-31 10:00:10
  • srore是什么意思中文(sore是什么意思?)2026-01-31 10:00:10
  • 全屏图片