Java教程

Java线程池基础入门和简单实践以及使用技巧,成长路线图

本文主要是介绍Java线程池基础入门和简单实践以及使用技巧,成长路线图,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
## Cache aside `Cache aside`也就是`旁路缓存`,是比较常用的缓存策略。 **(1)`读请求`常见流程** ![](http://www.www.zyiz.net/i/li/?n=2&i=images/20210630/1624992372769146.jpg) 应用首先会判断缓存是否有该数据,缓存命中直接返回数据,缓存未命中即缓存穿透到数据库,从数据库查询数据然后回写到缓存中,最后返回数据给客户端。 **(2)`写请求`常见流程** ![](http://www.www.zyiz.net/i/li/?n=2&i=images/20210630/1624992372659939.jpg) 首先更新数据库,然后从缓存中删除该数据。 看了写请求的图之后,有些同学可能要问了:为什么要删除缓存,直接更新不就行了?这里涉及到几个坑,我们一步一步踩下去。 ## Cache aside踩坑 Cache aside策略如果用错就会遇到深坑,下面我们来逐个踩。 **踩坑一:先更新数据库,再更新缓存** 如果同时有两个`写请求`需要更新数据,每个写请求都先更新数据库再更新缓存,在并发场景可能会出现数据不一致的情况。 ![](http://www.www.zyiz.net/i/li/?n=2&i=images/20210630/1624992373506859.jpg) 如上图的执行过程: (1)`写请求1`更新数据库,将 age 字段更新为18; (2)`写请求2`更新数据库,将 age 字段更新为20; (3)`写请求2`更新缓存,缓存 age 设置为20; (4)`写请求1`更新缓存,缓存 age 设置为18; 执行完预期结果是数据库 age 为20,缓存 age 为20,结果缓存 age为18,这就造成了缓存数据不是最新的,出现了脏数据。 **踩坑二:先删缓存,再更新数据库** 如果`写请求`的处理流程是`先删缓存再更新数据库`,在一个`读请求`和一个`写请求`并发场景下可能会出现数据不一致情况。 ![](http://www.www.zyiz.net/i/li/?n=2&i=images/20210630/1624992373990492.jpg) 如上图的执行过程: (1)`写请求`删除缓存数据; (2)`读请求`查询缓存未击中(Hit Miss),紧接着查询数据库,将返回的数据回写到缓存中; (3)`写请求`更新数据库。 整个流程下来发现`数据库`中age为20,`缓存`中age为18,缓存和数据库数据不一致,缓存出现了脏数据。 **踩坑三:先更新数据库,再删除缓存** 在实际的系统中针对`写请求`还是推荐`先更新数据库再删除缓存`,但是在理论上还是存在问题,以下面这个例子说明。 ![](http://www.www.zyiz.net/i/li/?n=2&i=images/20210630/1624992373960485.jpg) 如上图的执行过程: (1)`读请求`先查询缓存,缓存未击中,查询数据库返回数据; (2)`写请求`更新数据库,删除缓存; (3)`读请求`回写缓存; 整个流程操作下来发现`数据库age为20`,`缓存age为18`,即数据库与缓存不一致,导致应用程序从缓存中读到的数据都为旧数据。 但我们仔细想一下,上述问题发生的概率其实非常低,因为通常数据库更新操作比内存操作耗时多出几个数量级,上图中最后一步回写缓存(set age 18)速度非常快,通常会在更新数据库之前完成。 如果这种极端场景出现了怎么办?我们得想一个兜底的办法:`缓存数据设置过期时间`。通常在系统中是可以允许少量的数据短时间不一致的场景出现。 ## Read through 在 Cache Aside 更新模式中,应用代码需要维护两个数据源头:一个是缓存,一个是数据库。而在?`Read-Through`?策略下,应用程序无需管理缓存和数据库,只需要将数据库的同步委托给缓存提供程序?`Cache Provider`?即可。所有数据交互都是通过`抽象缓存层`完成的。 ![](http://www.www.zyiz.net/i/li/?n=2&i=images/20210630/1624992374128313.jpg) 如上图,应用程序只需要与`Cache Provider`交互,不用关心是从缓存取还是数据库。 在进行大量读取时,`Read-Through`?可以减少数据源上的负载,也对缓存服务的故障具备一定的弹性。如果缓存服务挂了,则缓存提供程序仍然可以通过直接转到数据源来进行操作。 `Read-Through 适用于多次请求相同数据的场景`,这与 Cache-Aside 策略非常相似,但是二者还是存在一些差别,这里再次强调一下: * 在 Cache-Aside 中,应用程序负责从数据源中获取数据并更新到缓存。 * 在 Read-Through 中,此逻辑通常是由独立的缓存提供程序(Cache Provider)支持。 ## Write through `Write-Through`?策略下,当发生数据更新(Write)时,缓存提供程序?`Cache Provider`?负责更新底层数据源和缓存。 缓存与数据源保持一致,并且写入时始终通过`抽象缓存层`到达数据源。 `Cache Provider`类似一个代理的作用。 ![](http://www.www.zyiz.net/i/li/?n=2&i=images/20210630/1624992374492377.jpg) ## Write behind `Write behind`在一些地方也被成为`Write back`, 简单理解就是:应用程序更新数据时只更新缓存,?`Cache Provider`每隔一段时间将数据刷新到数据库中。说白了就是`延迟写入`。 ![](http://www.www.zyiz.net/i/li/?n=2&i=images/20210630/1624992374469150.jpg) 如上图,应用程序更新两个数据,Cache Provider 会立即写入缓存中,但是隔一段时间才会批量写入数据库中。 这种方式有优点也有缺点: * `优点`是数据写入速度非常快,适用于频繁写的场景。 * `缺点`是缓存和数据库不是强一致性,对一致性要求高的系统慎用。 ![](http://www.www.zyiz.net/i/li/?n=2&i=images/20210630/1624992375269141.jpg) 最近我根据上述的技术体系图搜集了几十套腾讯、头条、阿里、美团等公司21年的面试题,把技术点整理成了视频(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节,由于篇幅有限,这里以图片的形式给大家展示一部分 [戳这里免费领取下面所有资料](https://docs.qq.com/doc/DSmxTbFJ1cmN1R2dB) ![](http://www.www.zyiz.net/i/li/?n=2&i=images/20210630/1624992376955079.jpg)
这篇关于Java线程池基础入门和简单实践以及使用技巧,成长路线图的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!