redis資料失效及springIOC的特性

redis資料失效的6種情況

失效----記憶體不足，還有寫操作的時候，redis如何執行？

LUR：近似算法，通路率算法，頻率算法

• 有效期過期政策，在全局資料範圍内，找到設定有效期的資料，删除通路頻率最低的，儲存新資料
• 全局過期政策，在全局資料範圍内，找通路頻率最低的資料删除

全局：随機算法

• 有效期過期政策，在全局資料範圍内，找有設定有效期的資料，随機删除一條
• 全局過期政策，全局資料範圍，随機删除一條

無：沒有任何算法

• 有效期，全局範圍内，找剩餘有效期最短的删除
• 永不，不删除任何資料，阻塞：寫操作阻塞

1.volatile-lru:從設定了過期時間的資料集中，選擇最近最久未使用的資料釋放

2.allkeys-lru:從資料集中(包括設定過期時間以及未設定過期時間的資料集中)，選擇最近最久未使用的資料釋放

3.volatile-random:從設定了過期時間的資料集中，随機選擇一個資料進行釋放

4.allkeys-random:從資料集中(包括了設定過期時間以及未設定過期時間)随機選擇一個資料進行入釋放

5.volatile-ttl：從設定了過期時間的資料集中，選擇馬上就要過期的資料進行釋放操作

6.noeviction：不删除任意資料(但redis還會根據引用計數器進行釋放呦~),這時如果記憶體不夠時，會直接傳回錯誤

spring: 描述ioc特性，并考慮是否存在潛在的安全問題

1.IOC是什麼

IOC控制反轉：控制-是對對象生命周期的控制

反轉-是說将控制權力交出來

将對象的聲明周期控制權力交給spring容器。

2.實作的角度

BeanFactory：簡單的bean對象工廠，隻能建立對象，并維護對象的屬性注入。

ApplicationContext：應用上下文。應用-一個整體的代碼系統，就是啟動一次JVM虛拟機，上下文-和左側定義相關的所有的資料集合。除BeanFactory功能之外，還包括：代理建立，事務管理，本地加載，表達式解析，測試環境準備等

3.功能的角度

解耦合，代碼中沒有對象生命周期的管理，都是面向接口和父類型開發的，是以各類型之間的耦合極低。需要修改實作的時候，使用擴充的方式，配合配置讓容器提供新的實作即可。

4.安全的角度

潛在安全問題：

記憶體問題：springIoc容器預設啟動的時候，建立所管理的所有bean對象。對象是否一定使用？對記憶體的壓力是否過大?考慮局部lazy-init方式初始化環境。

bean數量問題：spring容器預設對bean的管理是單例的。如果使用預設管理方式，spring管理的bean對象，必須是線程安全的。否則需要提供scope=prototype才能解決單例線程安全隐患。

容器數量問題：如：在springmvc開發中，有兩個容器ContextLoaderListener建立的，DispatcherServlet建立的，這兩個容器适父子容器，父容器是ContextLoaderListener建立的，子容器可以直接使用父容器管理的所有bean對象（普通的bean，代理的bean，通知bean等）。父容器不能使用子容器管理的任何bean對象。且所有容器管理的properties（property-placeholder加載的内容）是容器獨享的。

2.為什麼使用ioc

第一，對象的執行個體化不是很簡單的一件事，比如對象的關系比較複雜，依賴關系往往需要程式員維護，這是很麻煩的一件事情

第二，解耦，由容器去維護具體的對象

第三，托管了類的産生過程，比如我們需要在類的産生過程中做一些處理，最直接的例子就是代理，如果有容器程式可以把這部分過程交給容器，應用程式則無需去關心類是如何完成代理的

3.ioc與DI

在spring當中實作IOC的這個目标用的就是DI

DI依賴注入，

注入：容器把依賴對象填充到被依賴對象的過程叫做注入，比如容器把Order執行個體化，然後把Order通過各種方式 填充到User類中Order屬性的過程叫做注入。這裡的各種方式 分為兩種方式分别是構造方法注入和setter注入，

dict擴容問題