Caffeine Cache和Ehcache3.x 进程缓存性能比较

Local Cache(一)Caffeine Cache介绍 一、 阅读详情

Spring默认提供的:ConcurrentMapCache。使用它的原因是它是spring-context内置的,无需额外导包就能使用,超好用的

但在实际开发过程中,Spring内建提供的实现显然是满足不了日益复杂的需求的,现实情况是很小有可能直接使用ConcurrentMapCacheManager和ConcurrentMapCache去作为存储方案,毕竟它提供的能力非常有限,有如下两个致命的不足:

  1. 基于本地内存的缓存,且它无法用于分布式环境
  2. 没有缓存过期时间Expire

就单单是这两点没有得到满足,在实际开发中就足以有理由抛弃内置实现,而需要引入第三方更为强大的缓存实现方案。

Spring Cache缓存抽象的实现产品

缓存标准方面:一个是JSR107,一个是Spring Cache,前面也说了Spring Cache已经成为了现实中的标准,所以市面上它的实现产品非常丰富,因此本文主要看看基于Spring Cache的实现产品的集成方案。

Spring Cache它也是支持JSR107规范的,可谓非常的友好。(请导入spring-contextr-support包)

要想了解常用的、流行的Spring Cache的实现方案有哪些,我推荐一个由SpringBoot提枚举类CacheType,它里面收纳得还是比较全面的:

此枚举是SpringBoot提供的供以参考,但本文内容和SpringBoot没有半毛钱关系
public enum CacheType {
	GENERIC, // 使用的SimpleCacheManager(自己手动指定Cache,可任意类型Cache实现哦)
	JCACHE, // 使用org.springframework.cache.jcache.JCacheCacheManager
	EHCACHE, // 使用org.springframework.cache.ehcache.EhCacheCacheManager
	HAZELCAST, // 使用com.hazelcast.spring.cache.HazelcastCacheManager
	INFINISPAN, // 使用org.infinispan.spring.provider.SpringEmbeddedCacheManager
	COUCHBASE, // 使用com.couchbase.client.spring.cache.CouchbaseCacheManager
	REDIS, // 使用org.springframework.data.redis.cache.RedisCacheManager,依赖于RedisTemplate进行操作
	CAFFEINE, // 使用org.springframework.cache.caffeine.CaffeineCacheManager
	@Deprecated
	GUAVA, // 使用org.springframework.cache.guava.GuavaCacheManager,已经过期不推荐使用了
	SIMPLE, // 使用ConcurrentMapCacheManager
	NONE; // 使用NoOpCacheManager,表示禁用缓存
}

这些就是业内最为流行的那些缓存实现,下面做简单的介绍作为参考:

  1. EhCache:一个纯Java的进程内缓存框架,具有快速、精干等特点。因为它是纯Java进程的,所以也是基于本地缓存的。(注意:EhCache2.x和EhCache3.x差异巨大且不兼容)
  2. Hazelcast:基于内存的数据网格。虽然它基于内存,但是分布式应用程序可以使用Hazelcast进行分布式缓存、同步、集群、处理、发布/订阅消息等。(如果你正在寻找基于内存的、高速的、可弹性扩展的、支持分布式的、对开发者友好的NoSQL,Hazelcast是一个很棒的选择,它的理念是用应用服务的内存换取效率,成本较高)
    1.从com.hazelcast.spring.cache.HazelcastCacheManager这个包名中也能看出,是它自己实现的Spring Cache标准,而不是spring-data帮它实现的(类似MyBatis集成Spring),但它凭借自己的足够优秀,让Spring接受了它
  3. Infinispan:基于Apache 2.0协议的分布式键值存储系统,可以以普通java lib或者独立服务的方式提供服务,支持各种协议(Hot Rod, REST, WebSockets)。支持的高级特性包括:事务、事件通知、高级查询、分布式处理、off-heap及故障迁移。 它按照署模式分为嵌入式(Embedded)模式(基于本地内存)、Client-Server(C\S)模式。
  4. Couchbase:是一个非关系型数据库,它实际上是由couchdb+membase组成,所以它既能像couchdb那样存储json文档(类似MongoDB),也能像membase那样高速存储键值对。(新一代的NoSql数据库,国外挺火的)
  5. Redis:熟悉得不能再熟悉的分布式缓存,只有Client-Server(C\S)模式,单线程让它天生具有线程安全的特性。Java一般使用Jedis/Luttuce来操纵~
  6. Caffeine(咖啡因):Caffeine是使用Java8对Guava缓存的重写版本,一个接近最佳的的缓存库(号称性能最好)。Spring5已经放弃guava,拥抱caffeine,它的API保持了近乎和guava一致,但是性能上碾压它。
    1.guava是谷歌Google Guava工具包的,使用非常广泛。Caffeine长江后浪推前浪,性能上碾压了Guava,是它的替代品。
  7. SIMPLE:。。。。。(嗯~太简单都不想解释了)

进程缓存:Ehcache、Guava、Caffeine对比

首先这仨都作为进程缓存(本地缓存)的优秀开源产品,那么若我们要使用本地缓存来加速访问,选择哪种呢?下文做一个简单的对比:

  1. EhCache:是一个纯Java的进程内缓存框架,具有快速、精干等特点,是Hibernate、MyBatis默认的缓存提供。(备注:虽然EhCache3支持到了分布式,但它还是基于Java进程的缓存)

  2. Guava:它是Google Guava工具包中的一个非常方便易用的本地化缓存实现,基于LRU算法实现,支持多种缓存过期策略。它出现得非常早,有点廉颇老矣之感~

  3. Caffeine:是使用Java8对Guava缓存的重写版本,在Spring5中将取代了Guava,支持多种缓存过期策略。

说明:Caffeine它在性能上碾压其余两者,它可以完全的替代Guava,因为API上都差不多一致,并且它还提供了Adapter让Guava过度到Caffeine上来。
Caffeine被称为进程缓存之王

为何Guava被放弃了,但EhCache依旧坚挺?我个人认为主要是它具备了如下特点:

  1. 稳定,健壮
  2. 被认可:apache 2.0 license
  3. 读、写速度还是不错的
  4. 够简单
  5. 够秀珍(jar包很小)
  6. 够轻量(仅仅依赖slf4j这一个包)
  7. 好扩展(可自定义淘汰算法)
  8. 监听器
  9. Ehcache支持缓存数据到硬盘(它也支持内存级别的缓存,Ehcache3还支持了分布式的缓存)

成熟(MyBatis、Hibernate等知名产品都用它作为默认缓存方案)

Caffeine和Spring Cache整合

关于Caffeine的强悍之处,此处就不费笔墨了,总之两个字:优秀。若我们在Spring应用中需要使用Caffeine怎么办呢?当然最直接的使用方式是导入Jar包后,直接使用它的API:CacheManager和Cache等等。

当然,这不是本文要讲述的,本文主要是要让它和Spring集成,从而可以使用Spring Cache注解来直接操作缓存

整合Caffeine,其实Spring已经有个模块对它提供了支持:spring-context-support

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context-support</artifactId>
    <version>5.1.6.RELEASE</version>
</dependency>

此包属于spring-context的支持包,一般建议导入。它的内容如下:

在这里插入图片描述

需要注意的是,在Spring5之前,此包还默认提供了对Guava的支持,但在Spring5后彻底移除了,这也侧面证明Guava确实该退休了~。

集成第一步:除了导入support包,当然还得导入咖啡因的包:

<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <!-- 2019.2最新版本 caffeine是2015年才面市的,发展还是很迅速的-->
    <version>2.7.0</version>
</dependency>

实施之前,先简单看看spring-context-support提供的CaffeineCacheManager实现:

// @since 4.3   Requires Caffeine 2.1 or higher.显然我们都2.7版本 肯定满足呀
public class CaffeineCacheManager implements CacheManager {

	private final ConcurrentMap<String, Cache> cacheMap = new ConcurrentHashMap<>(16);
	// 默认能动态生成Cache,对使用者友好
	private boolean dynamic = true;
	// 默认使用的builder  可通过setCaffeine来自定这个cacheBuilder 
	// cacheBuilder.build()得到一个com.github.benmanes.caffeine.cache.Cache  让可以自定义N个参数
	private Caffeine<Object, Object> cacheBuilder = Caffeine.newBuilder();
	@Nullable
	private CacheLoader<Object, Object> cacheLoader;
	private boolean allowNullValues = true; // 是否允许null值

	// 一样的,两个构造函数。你可以指定,也可以让动态生成
	public CaffeineCacheManager() {
	}
	public CaffeineCacheManager(String... cacheNames) {
		setCacheNames(Arrays.asList(cacheNames));
	}
	...
	@Override
	@Nullable
	public Cache getCache(String name) {
		Cache cache = this.cacheMap.get(name);
		if (cache == null && this.dynamic) {
			synchronized (this.cacheMap) {
				cache = this.cacheMap.get(name);
				if (cache == null) {
					cache = createCaffeineCache(name);
					this.cacheMap.put(name, cache);
				}
			}
		}
		return cache;
	}

	// CaffeineCache实现了org.springframework.cache.Cache接口
	// 内部实现都是委托给com.github.benmanes.caffeine.cache.Cache<Object, Object>来做的
	protected Cache createCaffeineCache(String name) {
		return new CaffeineCache(name, createNativeCaffeineCache(name), isAllowNullValues());
	}
	...
}

它提供的Cache实现:CaffeineCache。非常简单,所有工作都委托给com.github.benmanes.caffeine.cache.Cache了,因此省略。

第二步:准备CacheConfig 配置文件

@EnableCaching
@Configuration
public class CacheConfig extends CachingConfigurerSupport {

    @Bean
    public CacheManager cacheManager() {
        CaffeineCacheManager cacheManager = new CaffeineCacheManager();
        // 方案一(常用):定制化缓存Cache
        cacheManager.setCaffeine(Caffeine.newBuilder()
                .expireAfterWrite(10, TimeUnit.MINUTES)
                .initialCapacity(100)
                .maximumSize(10_000))
        // 如果缓存种没有对应的value,通过createExpensiveGraph方法同步加载  buildAsync是异步加载
        //.build(key -> createExpensiveGraph(key))
        ;


        // 方案二:传入一个CaffeineSpec定制缓存,它的好处是可以把配置方便写在配置文件里
        //cacheManager.setCaffeineSpec(CaffeineSpec.parse("initialCapacity=50,maximumSize=500,expireAfterWrite=5s"));
        return cacheManager;
    }

}

@Service
public class CacheDemoServiceImpl implements CacheDemoService {

    @Cacheable(cacheNames = "demoCache", key = "#id")
    @Override
    public Object getFromDB(Integer id) {
        System.out.println("模拟去db查询~~~" + id);
        return "hello cache...";
    }
}

运行单测:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {RootConfig.class, CacheConfig.class})
public class TestSpringBean {

    @Autowired
    private CacheDemoService cacheDemoService;
    @Autowired
    private CacheManager cacheManager;

    @Test
    public void test1() {
        cacheDemoService.getFromDB(1);
        cacheDemoService.getFromDB(1);

        System.out.println("----------验证缓存是否生效----------");
        Cache cache = cacheManager.getCache("demoCache");
        System.out.println(cache);
        System.out.println(cache.get(1, String.class));
    }

}

打印结果:

模拟去db查询~~~1
----------验证缓存是否生效----------
org.springframework.cache.caffeine.CaffeineCache@4f74980d
hello cache...
从结果中可以得出结论:缓存生效。

(关于Caffeine的更多API以及它的高级使用,不是本文讨论的内容)

Ehcache2.x/Ehcache3.x和Spring Cache整合

Ehcache2.x和Ehcache3.x它最大的一个特点是:3.x不向下兼容2.x。从他俩的GAV坐标也能看出这种差异:

<!-- https://mvnrepository.com/artifact/net.sf.ehcache/ehcache -->
<dependency>
    <groupId>net.sf.ehcache</groupId>
    <artifactId>ehcache</artifactId>
    <version>2.10.6</version>
</dependency>

<!-- https://mvnrepository.com/artifact/org.ehcache/ehcache -->
<dependency>
    <groupId>org.ehcache</groupId>
    <artifactId>ehcache</artifactId>
    <version>3.7.1</version>
</dependency>

不仅仅GAV变了,包名也都换了,因此是二进制不兼容的,并且3.x和2.x的API都有非常大的差异。

虽然说2.x也还是维护着(毕竟有非常重的历史包袱),但是活跃度已经远不及3.x了,因此我认为拥抱EhCache3.x是大势所趋  

这里有意思的是,spring-context-support即使在Spring5后,默认支持的还是EhCache2.x版本(毕竟有很重的历史包袱在呢),并且没有提供3.x版本的支持,这应该也是为何你看到大多数人还只是在使用EhCache2.x的根本原因吧~

Ehcache2.x集成

Ehcache2.x的集成方案几乎同Caffeine,就不写了。

2.x配置CacheManager的时候,既能全用API方式。当然也能简便的使用ehcache.xml方式,内容形如下:

<?xml version="1.0" encoding="UTF-8"?>
<ehcache>
    <diskStore path="d:/ehcache/"></diskStore>
    
    <!-- 默认缓存配置 -->
    <defaultCache maxElementsInMemory="10000" eternal="false"
        timeToIdleSeconds="120" timeToLiveSeconds="120" overflowToDisk="true" />
    
    <!-- User缓存配置 -->
    <cache name="User" maxElementsInMemory="10000" eternal="false"
        timeToIdleSeconds="300" timeToLiveSeconds="600" overflowToDisk="true"/>

</ehcache>

关于xml配置文件的更多属性和含义,请参考官方文档的说明

Ehcache3.x集成

Ehcache3.x的社区比EhCache2.x活跃很多,所以拥抱和使用3.x版本似乎是必然的。但是奈何Spring并没有提供内置的CacheManager对3.x提供支持,因此此处我总结继承它的两种方案:

  1. 自己实现CacheManager和Cache等相关规范接口
  2. 使用JSR107的JCache(推荐)

上面截图我们能看到support包里是有对jcache(JSR107)的支持,而切好EhCache3.x它实现了JSR107规范(但没有实现Spring-Cache),为了集成它,我们就用现成的方案:jcache+EhCache3.x来实现对Spring的整合。

第一步:先导包

<dependency>
    <groupId>javax.cache</groupId>
    <artifactId>cache-api</artifactId>
    <version>1.1.1</version>
</dependency>

<dependency>
    <groupId>org.ehcache</groupId>
    <artifactId>ehcache</artifactId>
    <version>3.7.1</version>
</dependency>

先简单看看jcache中JCacheCacheManager的实现:

public class JCacheCacheManager extends AbstractTransactionSupportingCacheManager {

	// 可见JCacheCacheManager其实就相当于代理,实际做事的是javax.cache.CacheManager
	@Nullable
	private CacheManager cacheManager;
	private boolean allowNullValues = true;

	public JCacheCacheManager() {
	}
	public JCacheCacheManager(CacheManager cacheManager) {
		this.cacheManager = cacheManager;
	}
	...
	@Override
	public void afterPropertiesSet() {
		if (getCacheManager() == null) {
			setCacheManager(Caching.getCachingProvider().getCacheManager());
		}
		super.afterPropertiesSet();
	}

	// 它使用的是JCacheCache俩把javax.cache.Cache包装起来  类似于适配的效果
	@Override
	protected Collection<Cache> loadCaches() {
		CacheManager cacheManager = getCacheManager();
		Assert.state(cacheManager != null, "No CacheManager set");

		Collection<Cache> caches = new LinkedHashSet<>();
		for (String cacheName : cacheManager.getCacheNames()) {
			javax.cache.Cache<Object, Object> jcache = cacheManager.getCache(cacheName);
			caches.add(new JCacheCache(jcache, isAllowNullValues()));
		}
		return caches;
	}

	@Override
	protected Cache getMissingCache(String name) {
		CacheManager cacheManager = getCacheManager();
		Assert.state(cacheManager != null, "No CacheManager set");

		// Check the JCache cache again (in case the cache was added at runtime)
		javax.cache.Cache<Object, Object> jcache = cacheManager.getCache(name);
		if (jcache != null) {
			return new JCacheCache(jcache, isAllowNullValues());
		}
		return null;
	}
}

由此可见,实际上JCache就相当于对JSR107做了一层适配,让所有实现了JSR107的缓存方案,都能够用在Spring环境中。

第二步:准备配置(集成)方案,此处给出两种配置方案:

一、使用最容易的JCacheManagerFactoryBean + ehcache.xml的方式:

@EnableCaching
@Configuration
public class CacheConfig extends CachingConfigurerSupport {

    @Bean
    public JCacheManagerFactoryBean cacheManagerFactoryBean() throws IOException {
        JCacheManagerFactoryBean factoryBean = new JCacheManagerFactoryBean();
        // 配置全部写在ehcache.xml这个配置文件内~~~~
        factoryBean.setCacheManagerUri(new ClassPathResource("ehcache.xml").getURI());
        return factoryBean;
    }

    @Bean
    public CacheManager cacheManager(javax.cache.CacheManager cacheManager) {
        // 它必须要包装一个javax.cache.CacheManager,也就是Eh107CacheManager才行
        JCacheCacheManager cacheCacheManager = new JCacheCacheManager();
        // 方式一:使用`JCacheManagerFactoryBean` + xml配置文件的方式
        cacheCacheManager.setCacheManager(cacheManager);
        return cacheCacheManager;
}

ehcache.xml配置文件如下:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
        xmlns='http://www.ehcache.org/v3'
        xsi:schemaLocation="http://www.ehcache.org/v3 http://www.ehcache.org/schema/ehcache-core-3.1.xsd">

    <!-- <service>
      <jsr107:defaults>
        <jsr107:cache name="demoCache" template="heap-cache"/>
      </jsr107:defaults>
    </service> -->

    <cache-template name="heap-cache">
        <resources>
            <heap unit="entries">2000</heap>
            <offheap unit="MB">100</offheap>
        </resources>
    </cache-template>

	<!-- 注意:这个cache必须手动配置上,它并不会动态生成 -->
    <cache alias="demoCache" uses-template="heap-cache">
        <expiry>
            <ttl unit="seconds">40</ttl>
        </expiry>
    </cache>

</config>

运行上面的单测,结果如下:

模拟去db查询~~~1
----------验证缓存是否生效----------
org.springframework.cache.jcache.JCacheCache@1cc680e
hello cache...
缓存生效(使用的JCacheCache)。

它的基本原理是依赖于Caching.getCachingProvider().getCacheManager()这句代码来生成CacheManager。而EhCache提供了EhcacheCachingProvider实现了CachingProvider接口从而实现了getCacheManager()

使用分布式缓存Redis确实能应对非常多的场景,但是在真正意义上的优化、高速缓存等等都是必须对本地缓存有深入了解的,路远着呢,越来越有趣了

缓存类型及优缺点:Ehcache、Caffeine、Memcached和Redis的比较 本文将对比分析四种常见的缓存类型:Ehcache、Caffeine、Memcached和Redis。通过探讨它们的优点、缺点以及适用场景,帮助读者更好地理解如何根据实际需求选择合适的缓存技术。同时,本文还将简要介绍这四种缓存类型支持的数据类型 阅读详情

相关推荐

spring boot 使用 caffeine 缓存

缓存依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-cache</artifactId> </dependency> <dependency> <groupId&gt

kylin 414

Java 缓存介绍(Caffeine,EhCache)

Caffeine 一个高性能的缓存库,Caffeine 使用 Window TinyLfu 回收策略,可以提供了一个近乎最佳的命中率。 依赖 maven <dependency> <groupId>com.github.ben-manes.caffeine</groupId> <artifactId>caffeine</art...

lgxzzz的博客 2530

Caffeine与Guava对比

Caffeine/Guava性能测试 处于性能优化考虑,项目准备将本地缓存从guava cache 转到caffeine cache,于是着手对caffeine进行了一波调研,首先通过一系列测试,通过caffeine和guava从结果来看,在相同cpu负载下,Caffeine Cache的读取和写入速度优于Guava Cache,差距在4倍以上。 但在内存占用方面来看,两者无明显区别。 测试环境: CPU:i7-8700 3.20GHz 6核 内存:16g 系统:Windows 10 JDK版本:8 ID

zhangyunfeihhhh的博客 1万+

玩转Spring Cache --- 整合进程缓存之王Caffeine Cache和Ehcache3.x【享学Spring】

前言 前面文章大篇幅详细讲解了Spring Cache缓存抽象、三大缓存注解的工作原理等等。若是细心的小伙伴会发现:讲解的是我使用的缓存实现方案均是Spring默认提供的:ConcurrentMapCache。它是spring-context内置的,无需额外导包就能使用。 但在实际开发过程中,Spring内建提供的实现显然是满足不了日益复杂的需求的,现实情况是很小有可能直接使用Concurrent...

架构师:通透,才能写出好代码! 5745

SpringBoot整合J2Cache

SpringBoot整合J2Cache

大军的博客 2378

本地缓存解决方案Caffeine | Spring Cloud 38

Caffeine是一款高性能、最优缓存库。Caffeine是受Google guava启发的本地缓存(青出于蓝而胜于蓝),在Cafeine的改进设计中借鉴了 Guava 缓存和 ConcurrentLinkedHashMap,Guava缓存可以参考上篇:本地缓存解决方案GuavaCache | Spring Cloud 37,就和Mybatis与Mybatis Plus一样。Caffeine也是Spring5.X后使用的缓存框架,作为Spring推荐的缓存框架我们有必要了解一下。

gmHappy 1万+

本地缓存选型:Guava Cache、Caffeine 与 Cache2k

本文对比Guava Cache、Caffeine与Cache2k在游戏服本地缓存中的应用,通过玩家数据缓存实战案例,解析三者在淘汰算法、异步加载、性能及生态上的差异。结论:新项目首选Caffeine,性能优、支持异步加载且社区丰富;老项目可暂用Guava Cache;Cache2k适合对吞吐有极致要求的特殊场景。关键设计建议:区分refresh与expire、合理设置容量、结合过期与主动移除保障数据一致性。

qq_28112995的博客 687

多元相关性分析_PAST:最简便易用的统计学分析软件教程目录

欢迎来到PAST的世界!本教程并不是将PAST的所有功能均进行详细介绍,而只是挑选与生物、医学、微生物研究相关的统计学分析内容进行讲述。根据PAST内各项分析的标签分类,将该教程具体设置如下:PAST软件介绍PAST的基本信息数据的输入和修改数据的转换和标准化图像绘制 (Plot标签)点线图和直方图散点图条形图和箱须图饼图堆叠条形图三元相图气泡图单变量统计学分析 (Univariate标...

weixin_39605706的博客 3156

MyBatis集成Ehcache实现高性能二级缓存实战

缓存是提升Java应用读性能的核心技术,其本质是通过空间换时间,将高频、低变、计算成本高的查询结果暂存于内存,规避重复数据库访问。其底层原理依赖LRU/LFU等淘汰策略与TTL/TTI过期机制,在保障数据一致性前提下实现毫秒级响应。技术价值体现在显著降低DB负载、提升QPS、增强系统弹性,广泛应用于字典表、用户配置、商品分类等读多写少场景。本文聚焦MyBatis二级缓存扩展机制,结合Ehcache 3.x的JSR-107标准支持、堆外内存与JMX监控能力,提供可落地的整合方案与生产级调优实践。

weixin_34235457的博客 368

shopee app算法分析第一篇

shopee app算法分析第一篇分析完整算法大概要好几篇,耐心等待下.国内只会发律师函,牛逼,一个律师套话,一个律师发函,大意了(警惕卡通律师头像),希望law可以保护好你,还是干国外好.

2531

避开这5个坑!Tushare金融数据获取与分析的常见错误排查指南

本文详细解析了使用Tushare进行金融数据获取与分析时常见的5个问题,包括Token失效、数据缺失、频率限制、数据一致性和性能瓶颈,并提供了实用的解决方案和优化策略。通过Python代码示例和最佳实践,帮助金融数据分析师和量化开发者高效避开这些陷阱,提升工作效率。

x2y3z4a5b的博客 1037

【本地缓存】Java 中的 4 种本地缓存

是 Google 开发的 Guava 工具包中一套完善的JVM 本地缓存框架,底层实现的数据结构类似于,但是进行了更多的能力拓展,包括:缓存过期时间设置、缓存容量设置、多种淘汰策略、缓存监控等。是一个支持高并发的线程安全的本地缓存。多线程情况下也可以安全的访问或者更新 Cache,这些都是借鉴了的结果支持最大容量限制支持两种过期删除策略(插入时间和读取时间)支持简单的统计功能基于 LRU 算法实现Caffeine 官网Caffeine 是基于Java 1.8 的高性能本地缓存库。

sco5282的博客 1万+

我的GIT练习ONE

Git 是一个分布式版本控制及源代码管理工具;Git 可以为你的项目保存若干快照,以此来对整个项目进行版本管理每一次的练习,都是对自身知识的巩固,以及对自身知识的一个测试。

是个非常热爱生活、乐观、奋斗、努力的逗比青年 8871

【缓存】J2Cache —— 基于内存和 Redis 的两级 Java 缓存框架的使用方法

本文目录 一、J2Cache简介 二、数据读取 三、使用方法及实际示例 3.1 引用 Maven 3.2 准备配置 J2Cache 使用Ceffien作为一级缓存,使用Redis作为二级缓存时的配置 3.3 编写代码 3.3.1 Demo示例 3.3.2 实际案例 四、常见问题 4.1 J2Cache 的使用场景是什么? 4.2 为什么不能在程序中设置缓存的有效期 4.3 如何使用 memcached 作为二级缓存 4.4 使用何种 Redis 的存储模式最佳? generic

No8g攻城狮的博客 4565

【主题建模】一种基于深度学习的主题建模方法:BERTopic(实战篇)

BERTopic 是基于深度学习的一种主题建模方法。2018 年底,Devlin et al. 提出了 Bidirectional Encoder Representations from Transformers (BERT)。BERT 是一种用于 NLP 的预训练策略,它成功地利用了句子的深层语义信息。

Data · Model · Agent · Repeat 2万+

“/usr/lib/wsl/wsl-setup“ failed, exiting

WSL2安装Ubuntu时出现"wsl-setup failed"错误的解决方法 摘要:当Windows用户名包含中文字符时,安装WSL2+Ubuntu会出现"wsl-setup failed"错误。本文提供两种解决方案:1)修改中文用户名(风险较大);2)通过命令手动配置。推荐第二种方法:先使用"wsl -l -v"查看Ubuntu名称,再通过"wsl -d Ubuntu20.04 -e /bin/bash"命令启动WSL2系

猿小白的博客 997

ehcache 手动刷新缓存_缓存的那些事

​作者 | 黄永灿后端开发攻城狮,关注服务端技术与性能优化。什么时候需要缓存一般来说会从两个方面来判断是否需要缓存:CPU 占用:如果某些应用需要消耗大量的 CPU 资源去计算,例如你使用正则表达式比较频繁或者业务查询链很复杂时,而它又占用了很多 CPU 的话,那就应该使用缓存将结果缓存下来。数据库 IO 占用:如果你发现你的数据库连接池比较空闲,可以不用缓存。但是如果数据库连接池比较繁忙,甚至经...

weixin_42361708的博客 1172

Untiy之如何实现AI+MR (Pico4u 相机推流MR画面给Server做实时AI图像识别)

本文介绍了基于Pico4U企业版开发AI+MR应用的实现方案。文章详细说明了硬件准备步骤,包括购买企业版设备、申请相机权限和注册管理平台。重点讲解了Unity开发中获取摄像头画面的两种技术方案:通过Overlay直接渲染到Android Surface,或使用API获取图像数据转换为Texture。提供了完整的代码示例和权限配置说明,并揭示了底层通过JNI调用Android原生API的技术原理。该方案适用于带电操作等实习场景,可提升安全性和学习趣味性。

TxNet 1342

Caffeine本地缓存框架使用介绍

在异步模式下,如果多个线程同时访问同一个缓存项,可能会导致缓存穿透的问题。当调用 getUserById 方法时,会先从名为 userCache 的缓存中查找对应的用户信息,如果缓存中不存在,则执行方法的逻辑,并将返回的用户信息存储到 userCache 缓存中,并且将 userListCache 缓存中的所有数据移除。key():指定缓存的键值 key。@Cacheable 注解:使方法返回结果被缓存【返回结果为 NULL,则不进行缓存】,再次通过相同参数调用时,会直接从缓存获取,而不再执行该方法逻辑。

qq_38254740的博客 1514

银河麒麟高级服务器V11操作系统安装部署zabbix监控平台的实操保姆级教程

本文详细介绍了在《银河麒麟高级服务器V11上安部署Zabbix监控系统的全过程》涵盖了zabbix监控系统涉及到的所有软件安装、参数优化、服务启动验证及防火墙配置等一系列实操。其中关于安装过程报错undefined symbol: usmAES256CiscoPrivProtocol;ares_reinit等依赖库问题进行了详细记录与分析解决;还提供了Web前端中文显示修复方案和Admin密码修改方法。实现监控平台的100%部署上线,实现对业务系统的实时监控,保证业务的稳定运行。

提供C#相关开发 、云计算、运维测试、网络安全相关技术分享与服务,有意向可联系。 531

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

缓存选型避雷手册:从单体到微服务场景下的Ehcache/Caffeine/Memcached/Redis实战选择

本文深入探讨了从单体到微服务架构下缓存技术的选型策略,重点分析了Ehcache、Caffeine、Memcached和Redis的适用场景及调优技巧。通过实际电商案例,展示了如何根据业务需求选择最佳缓存方案,提升系统性能并降低数据库负载。

r2s3t4的博客 584

STM32F407中文手册

STM32f407中文手册 本参考手册面向应用开发人员,提供有关使用 STM32F405xx/07xx、STM32F415xx/17xx、 STM32F42xxx 和 STM32F43xxx 微控制器存储器与外设的完整信息。STM32F405xx/07xx、STM32F415xx/17xx、STM32F42xxx 和 STM32F43xxx 构成一个微 控制器系列,各产品具有不同的存储器大小、封装和外设。有关订购信息以及器件的机械与电气特性,请参见数据手册。有关 ARM Cortex™-M4F 内核的信息,请参见《Cortex™-M4F 技术参考手册》。

Java 中的 Caffeine 缓存详解

如果上述方案均不满足需求(例如需要 TTL 分桶、异步刷新等特殊逻辑),可以自行实现 Cache 和 CacheManager 接口,或继承 AbstractValueAdaptingCache。// 可覆盖 get、put 等方法添加额外逻辑。

qq_33807380的博客 636

计算机控制技术及应用

《计算机控制技术及应用》通过总结作者的科研成果和吸收国内外的先进理论、方法和技术,以计算机控制系统的网络化、开放化、智能化和集成化发展趋势为主线索,主要介绍计算机控制系统的基本概念和计算机控制系统的典型形式,计算机控制系统的数学描述与基本分析方法,以及数字PID控制器、最少拍控制系统、达林算法、状态变量设计法等设计方法及其各种改进算法。重点突出计算机控制系统输入输出通道接口的设计方法和典型控制系统的设计案例与实现方法等。

锂电池充电器电路设计 里面有电路

锂电池充电器电路设计 里面有电路 3.7V升压到5V电路设计。

J2CACHE 两级缓存框架

概述 缓存框架我们有ehcache 和 redis 分别是 本地内存缓存和 分布式缓存框架。在实际情况下如果单台机器 使用ehcache 就可以满足需求了,速度快效率高,有些数据如果需要多台机器共享这个时候怎么办呢,我们需要通过redis,将缓存存放到redis上面。 这也会导致一个问题,因为所有的请求都会到redis读取,当大量的读取会导致大量的网络流量,因此网络流量会成为访问的瓶颈。 J...

weixin_34038293的博客 590

@Cacheable Spring Cache缓存抽象的深入学习与使用【两万字】

基于Spring5.x,详细介绍了Spring Cache提供的基于注解的声明式缓存的概念以及使用!比如@Cacheable、@CacheEvict、@CachePut、@Caching、@CacheConfig注解。

终生学习践行者 2657

【j2cache二级缓存框架介绍】

J2Cache —— 基于内存和 Redis 的两级 Java 缓存框架   J2Cache 是 OSChina 目前正在使用的两级缓存框架(要求至少 Java 8)。第一级缓存使用内存(同时支持 Ehcache 2.x、Ehcache 3.x 和 Caffeine),第二级缓存使用 Redis 。 由于大量的缓存读取会导致 L2 的网络成为整个系统的瓶颈,因此 L1 的目标是降低对 L2 ...

791

Ehcache本地缓存核心架构与生产实践指南

本地缓存是提升应用性能的关键技术,通过在应用进程内部存储热点数据,实现纳秒级数据访问,有效降低数据库压力。其核心原理基于内存数据存储与生命周期管理,通过过期策略和逐出算法保障数据有效性。在技术价值上,本地缓存以零网络开销和极低延迟,为高并发场景提供稳定支撑。典型应用场景包括系统配置、会话信息和热点数据缓存。本文聚焦Ehcache这一成熟框架,深入解析其三级存储模型和事件监听机制,并结合缓存穿透、雪崩等常见问题,提供生产环境调优方案。

weixin_33895475的博客 284
上一篇: 分布式缓存Redis Cache
下一篇: 分布式数据库实践(一)
亦心ll
博客等级 码龄7年 10粉丝 12原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值