Spring Cache,从入门到真香

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 今天这篇文章是比较偏“教程”一点的文章。但也由浅入深,认真地分析了源码,并且介绍了一些在使用Spring Cache中常见的问题和解决方案,肯定是比简单的入门文档更有深度一些的,相信大家看了之后会有一定的收获。

荒腔走板


网络异常,图片无法展示
|

这是前两天我去西湖游玩的时候,玩到了夕阳西下的时间。于是我两就坐在西湖边上,静静地看太阳落山,等天空变黑,等灯火点亮。


我个人是比较喜欢有水的地方,尤其是湖。几年前我来过一次杭州,也走过一次西湖。那个时候还没毕业,来这边也是为了看一个工作机会。那天西湖下着小雨,我一个人顺着白堤,绕着西湖走了一圈,烟雨朦胧,宛如一幅山水画卷。


没想到几年以后,我会再次来到这个城市,在杭州工作和生活,西湖还是那个西湖,我也还是那个我,只是这次,变成了两个人看西湖。


国庆节没有出去旅游,也没有回家。就在周边玩一天,休息一天,这样比较轻松的节奏度过了这个假期。身心都得到了很好的放松,也想明白了一些困惑已久的事,整体来说还是没有虚度。


今天这篇文章是比较偏“教程”一点的文章。但也由浅入深,认真地分析了源码,并且介绍了一些在使用Spring Cache中常见的问题和解决方案,肯定是比简单的入门文档更有深度一些的,相信大家看了之后会有一定的收获。


为什么使用缓存

前几天我在文章《我是如何把一个15分钟的程序优化到了10秒的》中,提到了一些在代码层面优化性能的方法。其中第一个就是使用缓存。

使用缓存是一个很“高性价比”的性能优化方式,尤其是对于有大量重复查询的程序来说。通常来说,在WEB后端应用程序来说,耗时比较大的往往有两个地方:一个是查数据库,一个是调用其它服务的API(因为其它服务最终也要去做查数据库等耗时操作)。

重复查询也有两种。一种是我们在应用程序中代码写得不好,写的for循环,可能每次循环都用重复的参数去查询了。这种情况,比较聪明一点的程序员都会对这段代码进行重构,用Map来把查出来的东西暂时放在内存里,后续去查询之前先看看Map里面有没有,没有再去查数据库,其实这就是一种缓存的思想。

另一种重复查询是大量的相同或相似请求造成的。比如资讯网站首页的文章列表、电商网站首页的商品列表、微博等社交媒体热搜的文章等等,当大量的用户都去请求同样的接口,同样的数据,如果每次都去查数据库,那对数据库来说是一个不可承受的压力。所以我们通常会把高频的查询进行缓存,我们称它为“热点”。


为什么使用Spring Cache

前面提到了缓存有诸多的好处,于是大家就摩拳擦掌准备给自己的应用加上缓存的功能。但是网上一搜却发现缓存的框架太多了,各有各的优势,比如Redis、Memcached、Guava、Caffeine等等。

如果我们的程序想要使用缓存,就要与这些框架耦合。聪明的架构师已经在利用接口来降低耦合了,利用面向对象的抽象和多态的特性,做到业务代码与具体的框架分离。

但我们仍然需要显式地在代码中去调用与缓存有关的接口和方法,在合适的时候插入数据到缓存里,在合适的时候从缓存中读取数据。

想一想AOP的适用场景,这不就是天生就应该AOP去做的吗?

关于Spring AOP,可以参考我之前的文章《关于Spring AOP的灵魂十问》

是的,Spring Cache就是一个这个框架。它利用了AOP,实现了基于注解的缓存功能,并且进行了合理的抽象,业务代码不用关心底层是使用了什么缓存框架,只需要简单地加一个注解,就能实现缓存功能了。而且Spring Cache也提供了很多默认的配置,用户可以3秒钟就使用上一个很不错的缓存功能。

既然有这么好的轮子,干嘛不用呢?


如何使用Spring Cache

上面的3秒钟,绝对不夸张。使用SpringCache分为很简单的三步:加依赖,开启缓存,加缓存注解。

本文示例代码使用的是官方的示例代码,git地址:github.com/spring-guid…

1 加依赖

gradle:

implementation 'org.springframework.boot:spring-boot-starter-cache'

maven:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-cache</artifactId>
</dependency>

2 开启缓存

在启动类加上@EnableCaching注解即可开启使用缓存。

@SpringBootApplication
@EnableCaching
public class CachingApplication {
  public static void main(String[] args) {
    SpringApplication.run(CachingApplication.class, args);
  }
}

3 加缓存注解

在要缓存的方法上面添加@Cacheable注解,即可缓存这个方法的返回值。

@Override
@Cacheable("books")
public Book getByIsbn(String isbn) {
    simulateSlowService();
    return new Book(isbn, "Some book");
}
// Don't do this at home
private void simulateSlowService() {
    try {
        long time = 3000L;
        Thread.sleep(time);
    } catch (InterruptedException e) {
        throw new IllegalStateException(e);
    }
}

测试

@Override
public void run(String... args) {
    logger.info(".... Fetching books");
    logger.info("isbn-1234 -->" + bookRepository.getByIsbn("isbn-1234"));
    logger.info("isbn-4567 -->" + bookRepository.getByIsbn("isbn-4567"));
    logger.info("isbn-1234 -->" + bookRepository.getByIsbn("isbn-1234"));
    logger.info("isbn-4567 -->" + bookRepository.getByIsbn("isbn-4567"));
    logger.info("isbn-1234 -->" + bookRepository.getByIsbn("isbn-1234"));
    logger.info("isbn-1234 -->" + bookRepository.getByIsbn("isbn-1234"));
}

测试一下,可以发现。第一次和第二次(第二次参数和第一次不同)调用getByIsbn方法,会等待3秒,而后面四个调用,都会立即返回。


常用注解

Spring Cache有几个常用注解,分别为@Cacheable@CachePut@CacheEvict@Caching@CacheConfig。除了最后一个CacheConfig外,其余四个都可以用在类上或者方法级别上,如果用在类上,就是对该类的所有public方法生效,下面分别介绍一下这几个注解。

@Cacheable

@Cacheble注解表示这个方法有了缓存的功能,方法的返回值会被缓存下来,下一次调用该方法前,会去检查是否缓存中已经有值,如果有就直接返回,不调用方法。如果没有,就调用方法,然后把结果缓存起来。这个注解一般用在查询方法上

@CachePut

加了@CachePut注解的方法,会把方法的返回值put到缓存里面缓存起来,供其它地方使用。它通常用在新增方法上

@CacheEvict

使用了CacheEvict注解的方法,会清空指定缓存。一般用在更新或者删除的方法上

@Caching

Java注解的机制决定了,一个方法上只能有一个相同的注解生效。那有时候可能一个方法会操作多个缓存(这个在删除缓存操作中比较常见,在添加操作中不太常见)。

Spring Cache当然也考虑到了这种情况,@Caching注解就是用来解决这类情况的,大家一看它的源码就明白了。

public @interface Caching {
  Cacheable[] cacheable() default {};
  CachePut[] put() default {};
  CacheEvict[] evict() default {};
}

@CacheConfig

前面提到的四个注解,都是Spring Cache常用的注解。每个注解都有很多可以配置的属性,这个我们在下一节再详细解释。但这几个注解通常都是作用在方法上的,而有些配置可能又是一个类通用的,这种情况就可以使用@CacheConfig了,它是一个类级别的注解,可以在类级别上配置cacheNames、keyGenerator、cacheManager、cacheResolver等。


常用注解的配置

这部分我们最好是结合源码来看,才能更好地理解这些配置的运作机制。

源码:解析注解的时机

这一节主要是源码解析,有点晦涩,对源码不感兴趣的同学可以跳过。但如果想要弄清楚Spring Cache运作的原理,还是推荐一看的。

前面提到的几个注解@Cacheable、@CachePut、@CacheEvict、@CacheConfig,都有一些可配置的属性。这些配置的属性都可以在抽象类CacheOperation及其子类中可以找到。它们大概是这样的关系:

网络异常,图片无法展示
|

看到这里不得不佩服,这继承用得,妙啊。

解析每个注解的代码在SpringCacheAnnotationParser类中可以找到,比如parseEvictAnnotation方法,里面就有这么一句:

builder.setCacheWide(cacheEvict.allEntries());

明明注解里叫allEntries,但是CacheEvictOperation里却叫cacheWide?看了下作者,都是多个作者,但第一作者都是一个叫Costin Leau的哥们,我对这个命名还是有一点小小的困惑。。。看来大佬们写代码也会有命名不一致的问题

那这个SpringCacheAnnotationParser是在什么时候被调用的呢?很简单,我们在这个类的某个方法上打个断点,然后debug就行了,比如parseCacheableAnnotation方法。

网络异常,图片无法展示
|

在debug界面,可以看到调用链非常长,前面是我们熟悉的IOC注册Bean的一个流程,直到我们看到了一个叫做AbstractAutowireCapableBeanFactory的BeanFactory,然后这个类在创建Bean的时候会去找是否有Advisor。正好Spring Cache源码里就定义了这么一个Advisor:BeanFactoryCacheOperationSourceAdvisor

这个Advisor返回的PointCut是一个CacheOperationSourcePointcut,这个PointCut复写了matches方法,在里面去获取了一个CacheOperationSource,调用它的getCacheOperations方法。这个CacheOperationSource是个接口,主要的实现类是AnnotationCacheOperationSource。在findCacheOperations方法里,就会调用到我们最开始说的SpringCacheAnnotationParser了。

这样就完成了基于注解的解析。

入口:基于AOP的拦截器

那我们实际调用方法的时候,是怎么处理的呢?我们知道,使用了AOP的Bean,会生成一个代理对象,实际调用的时候,会执行这个代理对象的一系列的Interceptor。Spring Cache使用的是一个叫做CacheInterceptor的拦截器。我们如果加了缓存相应的注解,就会走到这个拦截器上。这个拦截器继承了CacheAspectSupport类,会执行这个类的execute方法,这个方法就是我们要分析的核心方法了。

@Cacheable的sync

我们继续看之前提到的execute方法,该方法首先会判断是否是同步。这里的同步配置是用的@Cacheable的sync属性,默认是false。如果配置了同步的话,多个线程尝试用相同的key去缓存拿数据的时候,会是一个同步的操作

网络异常,图片无法展示
|

我们来看看同步操作的源码。如果判断当前需要同步操作(1),首先会去判断当前的condition是不是符合条件(2)。这里的condition也是@Cacheable中定义的一个配置,它是一个EL表达式,比如我们可以这样用来缓存id大于1的Book:

@Override
@Cacheable(cacheNames = "books", condition = "#id > 1", sync = true)
public Book getById(Long id) {
    return new Book(String.valueOf(id), "some book");
}

如果不符合条件,就不使用缓存,也不把结果放入缓存,直接跳到5。否则,尝试获取key(3)。在获取key的时候,会先判断用户有没有定义key,它也是一个EL表达式。如果没有的话,就用keyGenerator生成一个key:

@Nullable
protected Object generateKey(@Nullable Object result) {
    if (StringUtils.hasText(this.metadata.operation.getKey())) {
        EvaluationContext evaluationContext = createEvaluationContext(result);
        return evaluator.key(this.metadata.operation.getKey(), this.metadata.methodKey, evaluationContext);
    }
    return this.metadata.keyGenerator.generate(this.target, this.metadata.method, this.args);
}

我们可以用这种方式手动指定根据id生成book-1book-2这样的key:

@Override
@Cacheable(cacheNames = "books",  sync = true, key = "'book-' + #id")
public Book getById(Long id) {
    return new Book(String.valueOf(id), "some book");
}

这里的key是一个Object对象,如果我们不在注解上面指定key,会使用keyGenerator生成的key。默认的keyGenerator是SimpleKeyGenerator,它生成的是一个SimpleKey对象,方法也很简单,如果没有入参,就返回一个EMPTY的对象,如果有入参,且只有一个入参,并且不是空或者数组,就用这个参数(注意这里用的是参数本身,而不是SimpleKey对象。否则,用所有入参包一个SimpleKey

源码:

@Override
public Object generate(Object target, Method method, Object... params) {
    return generateKey(params);
}
/**
   * Generate a key based on the specified parameters.
   */
public static Object generateKey(Object... params) {
    if (params.length == 0) {
        return SimpleKey.EMPTY;
    }
    if (params.length == 1) {
        Object param = params[0];
        if (param != null && !param.getClass().isArray()) {
            return param;
        }
    }
    return new SimpleKey(params);
}

看到这里你一定有一个疑问吧,这里只用入参,没有类名和方法名的区别,那如果两个方法入参一样,岂不是key冲突了?

你的感觉没错,大家可以试一下这两个方法:

// 定义两个参数都是String的方法
@Override
@Cacheable(cacheNames = "books", sync = true)
public Book getByIsbn(String isbn) {
    simulateSlowService();
    return new Book(isbn, "Some book");
}
@Override
@Cacheable(cacheNames = "books", sync = true)
public String test(String test) {
    return test;
}
// 调用这两个方法,用相同的参数"test"
logger.info("test getByIsbn -->" + bookRepository.getByIsbn("test"));
logger.info("test test -->" + bookRepository.test("test"));

你会发现两次生成的key相同,然后在调用test方法的时候,控制台会报错:

Caused by: java.lang.ClassCastException: class com.example.caching.Book cannot be cast to class java.lang.String (com.example.caching.Book is in unnamed module of loader 'app'; java.lang.String is in module java.base of loader 'bootstrap')
  at com.sun.proxy.$Proxy33.test(Unknown Source) ~[na:na]
  at com.example.caching.AppRunner.run(AppRunner.java:23) ~[main/:na]
  at org.springframework.boot.SpringApplication.callRunner(SpringApplication.java:795) ~[spring-boot-2.3.2.RELEASE.jar:2.3.2.RELEASE]
  ... 5 common frames omitted

Book不能强转成String,因为我们第一次调用getByIsbn方法的时候,生成的key是test,然后换成了返回值Book对象到缓存里面。而调用test方法的时候,生成的key还是test,就会取出Book,但是test方法的返回值是String,所以会尝试强转到String,结果发现强转失败。

我们可以自定义一个keyGenerator来解决这个问题:

@Component
public class MyKeyGenerator implements KeyGenerator {
    @Override
    public Object generate(Object target, Method method, Object... params) {
        return target.getClass().getName() + method.getName() + 
                Stream.of(params).map(Object::toString).collect(Collectors.joining(","));
    }
}

然后就可以在配置里面使用这个自定义的MyKeyGenerator了,再次运行程序,就不会出现上述问题。

@Override
@Cacheable(cacheNames = "books", sync = true, keyGenerator = "myKeyGenerator")
public Book getByIsbn(String isbn) {
    simulateSlowService();
    return new Book(isbn, "Some book");
}
@Override
@Cacheable(cacheNames = "books", sync = true, keyGenerator = "myKeyGenerator")
public String test(String test) {
    return test;
}

接着往下看,可以看到我们得到了一个Cache。这个Cache是在我们调用CacheAspectSupport的execute方法的时候,会new一个CacheOperationContext。在这个Context的构造方法里,会用cacheResolver去解析注解中的Cache,生成Cache对象。

默认的cacheResolver是SimpleCacheResolver,它从CacheOperation中取得配置的cacheNames,然后用cacheManager去get一个Cache。这里的cacheManager是用于管理Cache的一个容器,默认的cacheManager是ConcurrentMapCacheManager。听名字就知道是基于ConcurrentMap来做的了,底层是ConcurrentHashMap。

那这里的Cache是什么东西呢?Cache就对“缓存容器”的一个抽象,包含了缓存会用到的get、put、evict、putIfAbsent等方法。

不同的cacheNames会对应不同的Cache对象,比如我们可以在一个方法上定义两个cacheNames,虽然也可以用value,它是cacheNames的别名,但如果有多个配置的时候,更推荐用cacheNames,因为这样具有更好的可读性。

@Override
@Cacheable(cacheNames = {"book", "test"})
public Book getByIsbn(String isbn) {
    simulateSlowService();
    return new Book(isbn, "Some book");
}

默认的Cache是ConcurrentMapCache,它也是基于ConcurrentHashMap的。

但这里有个问题,我们回到上面的execute方法的代码,发现如果设置了sync为true,它取的是第一个Cache,而没有管剩下的Cache。所以如果你配置了sync为true,只支持配置一个cacheNames,如果配了多个,就会报错:

@Cacheable(sync=true) only allows a single cache on...

继续往下看,发现调用的是Cache的get(Object, Callcable)方法。这个方法会先尝试去缓存中用key取值,如果取不到在调用callable函数,然后加到缓存里。Spring Cache也是期望Cache的实现类在这个方法内部实现“同步”的功能。

所以我们再回过头去看Cacheable中sync属性上方的注释,它写到:使用sync为true,会有这些限制:

  1. 不支持unless,这个从代码可以看到,只支持了condition,没有支持unless;这个我没想清楚为什么。。。但Interceptor代码就是这样写的。
  2. 只能有一个cache,因为代码就写死了一个。我猜这是为了更好地支持同步,它把同步放到了Cache里面去实现。
  3. 没有不支持其它的Cache操作,代码里面写死了,只支持Cachable,我猜这也是为了支持同步。

其它操作

如果sync为false呢?

继续往下看execute的代码,大概经历了下面这些步骤:

  1. 尝试在方法调用前删除缓存,这个在@CacheEvict配置的beforeInvocation,默认为false(如果为true才会在这一步删除缓存);
  2. 尝试获取缓存;
  3. 如果第2步获取不到,尝试获取Cachable的注解,生成相应的CachePutRequest;
  4. 如果第2步获取到了,并且没有CachPut注解,就直接从缓存中获取值。否则,调用目标方法;
  5. 解析CachePut注解,同样生成相应的CachePutRequest;
  6. 执行所有的CachePutRequest;
  7. 尝试在方法调用后删除缓存,如果@CacheEvict配置的beforeInvocation为false会删除缓存

至此,我们就结合源码解释完了所有的配置发生作用的时机。


使用其它缓存框架

如果要使用其它的缓存框架,应该怎么做呢?

通过上面的源码分析我们知道,如果要使用其它的缓存框架,我们只需要重新定义好CacheManagerCacheResolver这两个Bean就行了。

事实上,Spring会自动检测我们是否引入了相应的缓存框架,如果我们引入了spring-data-redis,Spring就会自动使用spring-data-redis提供的RedisCacheManager,RedisCache。

如果我们要使用Caffeine框架。只需要引入Caffeine,Spring Cache就会默认使用CaffeineCacheManager和CaffeineCache。

implementation 'org.springframework.boot:spring-boot-starter-cache'
implementation 'com.github.ben-manes.caffeine:caffeine'

Caffeine是一个性能非常高的缓存框架,它使用了Window TinyLfu回收策略,提供了一个近乎最佳的命中率

Spring Cache还支持各种配置,在CacheProperties类里面,里面还提供了各种主流的缓存框架的特殊配置。比如Redis的过期时间等(默认永不过期)。

private final Caffeine caffeine = new Caffeine();
private final Couchbase couchbase = new Couchbase();
private final EhCache ehcache = new EhCache();
private final Infinispan infinispan = new Infinispan();
private final JCache jcache = new JCache();
private final Redis redis = new Redis();


使用缓存带来的问题

双写不一致

使用缓存会带来许多问题,尤其是高并发下,包括缓存穿透、缓存击穿、缓存雪崩、双写不一致等问题。具体的问题介绍和常用的解决方案可以参考我的个人网站上的文章《缓存常见问题及解决方案》。

其中主要聊一下双写不一致的问题,这是一个比较常见的问题,其中一个常用的解决方案是,更新的时候,先删除缓存,再更新数据库。所以Spring Cache的@CacheEvict会有一个beforeInvocation的配置。

但使用缓存通常会存在缓存中的数据和数据库中不一致的问题,尤其是调用第三方接口,你不会知道它什么时候更新了数据。但使用缓存的业务场景很多时候并不需求数据的强一致,比如首页的热点文章,我们可以让缓存一分钟失效,这样就算一分钟内,不是最新的热点排行也没关系。

占用额外的内存

这个是无可避免的。因为总要有一个地方去放缓存。不管是ConcurrentHashMap也好,Redis也好,Caffeine也好,总归是会占用额外的内存资源去放缓存的。但缓存的思想正是用空间去换时间,有时候占用这点额外的空间对于时间上的优化来说,是非常值得的。

这里需要注意的是,SpringCache默认使用的是ConcurrentHashMap,它不会自动回收key,所以如果使用默认的这个缓存,程序就会越来越大,并且得不到回收。最终可能导致OOM。

我们来模拟实验一下:

@Component
public class MyKeyGenerator implements KeyGenerator {
    @Override
    public Object generate(Object target, Method method, Object... params) {
        // 每次都生成不同的key
        return UUID.randomUUID().toString();
    }
}
//调它个100w次
for (int i = 0; i < 1000000; i++) {
    bookRepository.test("test");
}

然后把最大内存设置成20M: -Xmx20M

我们先来测试默认的基于ConcurrentHashMap的缓存,发现它很快就会报OOM。

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "RMI TCP Connection(idle)"

我们使用Caffeine,并且配置一下它的最大容量:

spring:
  cache:
    caffeine:
      spec: maximumSize=100

再次运行程序,发现正常运行,不会报错。

所以如果是用基于同一个JVM内存的缓存的话,个人比较推荐使用Caffeine,强烈不推荐用默认的基于ConcurrentHashMap的实现。

那什么情况适合用Redis这种需要调用第三方进程的缓存呢?如果你的应用程序是分布式的,一个服务器查询出来后,希望其它服务器也能用这个缓存,那就推荐使用基于Redis的缓存。

使用Spring Cache也有不好之处,就是屏蔽了底层缓存的特性。比如,很难做到不同的场景有不同的过期时间(但并不是做不到,也可以通过配置不同的cacheManager来实现)。但整体上来看,还是利大于弊的,大家自己衡量,适合自己就好。

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
2月前
|
XML Java 测试技术
Spring5入门到实战------17、Spring5新功能 --Nullable注解和函数式注册对象。整合JUnit5单元测试框架
这篇文章介绍了Spring5框架的三个新特性:支持@Nullable注解以明确方法返回、参数和属性值可以为空;引入函数式风格的GenericApplicationContext进行对象注册和管理;以及如何整合JUnit5进行单元测试,同时讨论了JUnit4与JUnit5的整合方法,并提出了关于配置文件加载的疑问。
Spring5入门到实战------17、Spring5新功能 --Nullable注解和函数式注册对象。整合JUnit5单元测试框架
|
2月前
|
Java
Spring5入门到实战------9、AOP基本概念、底层原理、JDK动态代理实现
这篇文章是Spring5框架的实战教程,深入讲解了AOP的基本概念、如何利用动态代理实现AOP,特别是通过JDK动态代理机制在不修改源代码的情况下为业务逻辑添加新功能,降低代码耦合度,并通过具体代码示例演示了JDK动态代理的实现过程。
Spring5入门到实战------9、AOP基本概念、底层原理、JDK动态代理实现
|
2月前
|
XML Java 数据格式
Spring5入门到实战------7、IOC容器-Bean管理XML方式(外部属性文件)
这篇文章是Spring5框架的实战教程,主要介绍了如何在Spring的IOC容器中通过XML配置方式使用外部属性文件来管理Bean,特别是数据库连接池的配置。文章详细讲解了创建属性文件、引入属性文件到Spring配置、以及如何使用属性占位符来引用属性文件中的值。
Spring5入门到实战------7、IOC容器-Bean管理XML方式(外部属性文件)
|
2月前
|
Java 数据库连接 Spring
后端框架入门超详细 三部曲 Spring 、SpringMVC、Mybatis、SSM框架整合案例 【爆肝整理五万字】
文章是关于Spring、SpringMVC、Mybatis三个后端框架的超详细入门教程,包括基础知识讲解、代码案例及SSM框架整合的实战应用,旨在帮助读者全面理解并掌握这些框架的使用。
后端框架入门超详细 三部曲 Spring 、SpringMVC、Mybatis、SSM框架整合案例 【爆肝整理五万字】
|
2月前
|
NoSQL Java Redis
Redis6入门到实战------ 八、Redis与Spring Boot整合
这篇文章详细介绍了如何在Spring Boot项目中整合Redis,包括在`pom.xml`中添加依赖、配置`application.properties`文件、创建配置类以及编写测试类来验证Redis的连接和基本操作。
Redis6入门到实战------ 八、Redis与Spring Boot整合
|
2月前
|
XML Java 数据格式
Spring5入门到实战------5、IOC容器-Bean管理(三)
这篇文章深入探讨了Spring5框架中IOC容器的高级Bean管理,包括FactoryBean的使用、Bean作用域的设置、Bean生命周期的详细解释以及Bean后置处理器的实现和应用。
Spring5入门到实战------5、IOC容器-Bean管理(三)
|
2月前
|
XML Java 数据格式
Spring5入门到实战------4、IOC容器-Bean管理XML方式、集合的注入(二)
这篇文章是Spring5框架的实战教程,主题是IOC容器中Bean的集合属性注入,通过XML配置方式。文章详细讲解了如何在Spring中注入数组、List、Map和Set类型的集合属性,并提供了相应的XML配置示例和Java类定义。此外,还介绍了如何在集合中注入对象类型值,以及如何使用Spring的util命名空间来实现集合的复用。最后,通过测试代码和结果展示了注入效果。
Spring5入门到实战------4、IOC容器-Bean管理XML方式、集合的注入(二)
|
2月前
|
SQL 数据库
Spring5入门到实战------13、使用JdbcTemplate操作数据库(批量增删改)。具体代码+讲解 【下篇】
这篇文章是Spring5框架的实战教程,深入讲解了如何使用JdbcTemplate进行数据库的批量操作,包括批量添加、批量修改和批量删除的具体代码实现和测试过程,并通过完整的项目案例展示了如何在实际开发中应用这些技术。
Spring5入门到实战------13、使用JdbcTemplate操作数据库(批量增删改)。具体代码+讲解 【下篇】
|
2月前
|
XML Java 数据格式
Spring5入门到实战------11、使用XML方式实现AOP切面编程。具体代码+讲解
这篇文章是Spring5框架的AOP切面编程教程,通过XML配置方式,详细讲解了如何创建被增强类和增强类,如何在Spring配置文件中定义切入点和切面,以及如何将增强逻辑应用到具体方法上。文章通过具体的代码示例和测试结果,展示了使用XML配置实现AOP的过程,并强调了虽然注解开发更为便捷,但掌握XML配置也是非常重要的。
Spring5入门到实战------11、使用XML方式实现AOP切面编程。具体代码+讲解
|
2月前
|
XML Java 数据格式
Spring5入门到实战------6、IOC容器-Bean管理XML方式(自动装配)
这篇文章是Spring5框架的入门教程,详细讲解了IOC容器中Bean的自动装配机制,包括手动装配、`byName`和`byType`两种自动装配方式,并通过XML配置文件和Java代码示例展示了如何在Spring中实现自动装配。
Spring5入门到实战------6、IOC容器-Bean管理XML方式(自动装配)

热门文章

最新文章