前言

最近一段时间发现经常看到很多人，对Spring源码比较感兴趣，日常开发中，无论你做什么什么项目，大部分都离不开Spring生态的那一套东西，所以很多人对Spring底层源码实现很感兴趣，但是有些从来没有接触过源码的开发者，在看Spring源码的过程中确实及其难受的，为什么，大部分人看源码基本都是debug一点一点去看的，最后发现，越追越离谱，越追越深，到最后都追到JDK源码了，也没有明白是什么意思！

对于学习源码，我的看法是，先去完全的熟悉它的用法，想一下如果让你来实现，你会怎么实现！有了这些想法之后，再去看源码去印证你自己的观点，远比你自己去死扣源码快的多。

而且，我问过一些读者还有同事，我发现有很多人，看源码容易陷入一个误区，就是刚开始看源码就死扣着一个细节不放，非得搞懂，我并不是说这样看源码有什么不对，但是在没有对整个框架有一个全局了解的情况下，不要这样看，你应该先把它的大体框架给搞清楚，在后再分功能一步一步的了解每一个功能项！这样做，首先你对整个框架的架构有了一个模糊的认识，再扣细节的途中有时候即使你不知道这个代码在干什么，你也隐约能猜出来，再通过debug 与自己的猜测相互印证，最终达到事半功倍的效果。当然这个建议只针对刚开始看源码的同学，如果你看的源码很多了，那么你肯定又自己的一套学习方法，可以的话，可以在评论区分享一下。

为了帮助一些萌新们或者想要了解Spring源码的小伙伴，我会把Spring的一些大体逻辑分析一下，让你了解整个Spring的骨架！

1、为什么使用redis

分析:博主觉得在项目中使用redis，主要是从两个角度去考虑:性能和并发。当然，redis还具备可以做分布式锁等其他功能，但是如果只是为了分布式锁这些其他功能，完全还有其他中间件(如zookpeer等)代替，并不是非要使用redis。因此，这个问题主要从性能和并发两个角度去答。
回答:如下所示，分为两点
（一）性能
如下图所示，我们在碰到需要执行耗时特别久，且结果不频繁变动的SQL，就特别适合将运行结果放入缓存。这样，后面的请求就去缓存中读取，使得请求能够迅速响应。

题外话：忽然想聊一下这个迅速响应的标准。其实根据交互效果的不同，这个响应时间没有固定标准。不过曾经有人这么告诉我:"在理想状态下，我们的页面跳转需要在瞬间解决，对于页内操作则需要在刹那间解决。另外，超过一弹指的耗时操作要有进度提示，并且可以随时中止或取消，这样才能给用户最好的体验。"
那么瞬间、刹那、一弹指具体是多少时间呢？
根据《摩诃僧祗律》记载

一刹那者为一念，二十念为一瞬，二十瞬为一弹指，二十弹指为一罗预，二十罗预为一须臾，一日一夜有三十须臾。

那么，经过周密的计算，一瞬间为0.36 秒,一刹那有 0.018 秒.一弹指长达 7.2 秒。
（二）并发
如下图所示，在大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。这个时候，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问数据库。

2、使用redis有什么缺点

分析:大家用redis这么久，这个问题是必须要了解的，基本上使用redis都会碰到一些问题，常见的也就几个。
回答:主要是四个问题
(一)缓存和数据库双写一致性问题
(二)缓存雪崩问题
(三)缓存击穿问题
(四)缓存的并发竞争问题

总结

其他的内容都可以按照路线图里面整理出来的知识点逐一去熟悉，学习，消化，不建议你去看书学习，最好是多看一些视频，把不懂地方反复看，学习了一节视频内容第二天一定要去复习，并总结成思维导图，形成树状知识网络结构，方便日后复习。

这里还有一份很不错的《Java基础核心总结笔记》，特意跟大家分享出来

目录：

部分内容截图：

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录