-
令牌桶具體的實(shí)現(xiàn) 底層的算法
-
令牌的qps是怎樣設(shè)置的披蕉？
-
老的項(xiàng)目占用資源較多，導(dǎo)致其他項(xiàng)目一直pending硝清，有沒有優(yōu)化的方式
-
Kafka為什么適合高數(shù)據(jù)量的消息發(fā)送及收集 零拷貝
-
Kafka如何保證消息不丟失的嵌戈？
-
緩存的過期時(shí)間是怎么考慮的
-
Redis雪崩 以及如何避免，如果出現(xiàn)雪崩共缕，該怎樣盡量避免較大的損失
-
redis穿透
-
熱點(diǎn)數(shù)據(jù)與數(shù)據(jù)庫一致性問題，
-
刪除緩存和數(shù)據(jù)更新并不是原子的士复，該怎么保證一致性
-
redis數(shù)據(jù)結(jié)構(gòu)的底層是什么樣的數(shù)據(jù)結(jié)構(gòu)
-
zset什么時(shí)候會(huì)用到图谷？
-
zset時(shí)間復(fù)雜度
-
MySQL事務(wù)隔離級(jí)別
-
事務(wù)ID 什么時(shí)候會(huì)有？事務(wù)開啟的時(shí)候就會(huì)有事務(wù)id嗎阱洪，還是commit的時(shí)候便贵？
innodb引擎下，會(huì)在每一行有兩個(gè)隱藏列冗荸，分別是創(chuàng)建事務(wù)ID與刪除事務(wù)ID
創(chuàng)建事務(wù)id <= 當(dāng)前事務(wù)id承璃，當(dāng)前事務(wù)id < 刪除事務(wù)id
在開啟事務(wù)之后 第一次執(zhí)行select 的時(shí)候 開啟一個(gè)view 后面的查詢只會(huì)查詢出這個(gè)時(shí)間的view的數(shù)據(jù)
-
ACID
原子性
一致性
隔離性
持久性
-
事務(wù)原子性是怎么保證的？
-
索引的結(jié)構(gòu)蚌本？
-
為什么用B+樹
-
非聚蔟索引和聚蔟索引的區(qū)別盔粹，葉子節(jié)點(diǎn)都存放的是什么
-
Spring中IOC是如何解決循環(huán)依賴問題的
Spring中解決循環(huán)依賴不是萬能的，只能解決scope單例的情況程癌，而且要求該對(duì)象沒有被代理過舷嗡，而且，針對(duì)在構(gòu)造方法中相互依賴的情況Spring也無力回天席楚。
Spring循環(huán)依賴的理論依據(jù)其實(shí)是Java基于引用傳遞咬崔，當(dāng)我們獲取到對(duì)象的引用時(shí)，對(duì)象的field或者或?qū)傩允强梢匝雍笤O(shè)置的烦秩。
Spring單例對(duì)象的初始化其實(shí)可以分為三步：
- createBeanInstance垮斯， 實(shí)例化，實(shí)際上就是調(diào)用對(duì)應(yīng)的構(gòu)造方法構(gòu)造對(duì)象只祠，此時(shí)只是調(diào)用了構(gòu)造方法兜蠕，spring xml中指定的property并沒有進(jìn)行populate
- populateBean，填充屬性抛寝，這步對(duì)spring xml中指定的property進(jìn)行populate
- initializeBean熊杨，調(diào)用spring xml中指定的init方法曙旭，或者AfterPropertiesSet方法
會(huì)發(fā)生循環(huán)依賴的步驟集中在第一步和第二步。
對(duì)于單例對(duì)象來說晶府，在Spring的整個(gè)容器的生命周期內(nèi)桂躏，有且只存在一個(gè)對(duì)象，很容易想到這個(gè)對(duì)象應(yīng)該存在Cache中川陆，Spring大量運(yùn)用了Cache的手段剂习，在循環(huán)依賴問題的解決過程中甚至使用了“三級(jí)緩存”。
singletonObjects 指單例對(duì)象的cache
singletonFactories 指單例對(duì)象工廠的cache
earlySingletonObjects 指提前曝光的單例對(duì)象的cache
關(guān)于Bean創(chuàng)建的過程较沪，首先Spring會(huì)嘗試從緩存中獲取鳞绕，這個(gè)緩存就是指singletonObjects，主要調(diào)用的方法是：
則移除對(duì)應(yīng)的singletonFactory,將singletonObject放入到earlySingletonObjects茬射，其實(shí)就是將三級(jí)緩存提升到二級(jí)緩存中贴见！
此處就是解決循環(huán)依賴的關(guān)鍵，這段代碼發(fā)生在createBeanInstance之后躲株，也就是說單例對(duì)象此時(shí)已經(jīng)被創(chuàng)建出來的。這個(gè)對(duì)象已經(jīng)被生產(chǎn)出來了镣衡，雖然還不完美（還沒有進(jìn)行初始化的第二步和第三步）霜定，但是已經(jīng)能被人認(rèn)出來了（根據(jù)對(duì)象引用能定位到堆中的對(duì)象），所以Spring此時(shí)將這個(gè)對(duì)象提前曝光出來讓大家認(rèn)識(shí)廊鸥，讓大家使用望浩。
這樣做有什么好處呢？讓我們來分析一下“A的某個(gè)field或者setter依賴了B的實(shí)例對(duì)象惰说，同時(shí)B的某個(gè)field或者setter依賴了A的實(shí)例對(duì)象”這種循環(huán)依賴的情況磨德。A首先完成了初始化的第一步，并且將自己提前曝光到singletonFactories中吆视，此時(shí)進(jìn)行初始化的第二步典挑，發(fā)現(xiàn)自己依賴對(duì)象B，此時(shí)就嘗試去get(B)啦吧，發(fā)現(xiàn)B還沒有被create您觉，所以走create流程，B在初始化第一步的時(shí)候發(fā)現(xiàn)自己依賴了對(duì)象A授滓，于是嘗試get(A)琳水，嘗試一級(jí)緩存singletonObjects(肯定沒有肆糕，因?yàn)锳還沒初始化完全)，嘗試二級(jí)緩存earlySingletonObjects（也沒有）在孝，嘗試三級(jí)緩存singletonFactories诚啃，由于A通過ObjectFactory將自己提前曝光了，所以B能夠通過ObjectFactory.getObject拿到A對(duì)象(雖然A還沒有初始化完全私沮，但是總比沒有好呀)始赎，B拿到A對(duì)象后順利完成了初始化階段1、2顾彰、3极阅，完全初始化之后將自己放入到一級(jí)緩存singletonObjects中。此時(shí)返回A中涨享，A此時(shí)能拿到B的對(duì)象順利完成自己的初始化階段2筋搏、3，最終A也完成了初始化厕隧，長(zhǎng)大成人奔脐，進(jìn)去了一級(jí)緩存singletonObjects中，而且更加幸運(yùn)的是吁讨，由于B拿到了A的對(duì)象引用髓迎，所以B現(xiàn)在hold住的A對(duì)象也蛻變完美了！一切都是這么神奇建丧！
Spring源碼初探-IOC(4)-Bean的初始化-循環(huán)依賴的解決
-
AQS
算法：
-
二叉樹前序遍歷排龄，非遞歸實(shí)現(xiàn)
