ugui batching規則分析：
ugui以canvas為單位進行批次生成和渲染，canvas可以巢狀包含canvas。
batching的生成和合併在canvas：：update裡：
batching主要流程如下:
計算canvas alpha，包括父canvas和巢狀canvas（alpha=0不生成合併批次）。
ui層次結構發生變化時，更新batch順序，對canvas下所有ui元素（canvasrenderer）按ui層次結構深度優先排序，生成ui instructions。
更新所有需要同步資料的renderer ui 資料，包括vertex, color, material, transform, rect, depth（按ui層次結構深度優先排序的深度）等。非活動（isactive() == false）且不強制更新的ui元素，將不同步資料。
canvas資料更新時（m_canvasdata.isdirty，如情況都可以引發：層次結構改變，同步關鍵資料，canvas.awake等），計算ui instructions的depth並排序、生成batch。
屬於同乙個atlas，那麼mask之間的元素可以進行合併；否則不能合併。mask外的元素和mask內的元素，無法合批。
更新：ui層次結構發生變化（orderisdirty），新增、刪除ui或ui子節點都會引起整個canvas ui順序更新。因此，應避免頻繁刪除/增加ui物件，使用gameobject.setactive。
depth計算演算法：
drawcall合批(batch)：
注意：在depth計算演算法中，由於要遍歷所有ui元素和已計算的底層ui元素（平方複雜度），原始碼中使用分組計算包圍盒矩形的方法加快計算，即16個ui元素為一組計算group rect，檢查是否與底層ui元素相交時，先計算是否與底層group相交，如果相交再與group中的元素做判定。
因此，ui元素數目過多和層次結構過於複雜，會影響排序和batch更新速度，合理規劃ui元素數量和層次結構可以提高ui效能。
小結：
從ugui批次合併生成規則可以看出，提高ui效能盡量注意以下幾點：
RedLock 原始碼分析及優化
redlock 全名叫做 redis distributed lock 即使用redis實現的分布式鎖 使用場景 多個服務間保證同一時刻同一時間段內同一使用者只能有乙個請求 防止關鍵業務出現併發攻擊 這個鎖的演算法實現了多redis例項的情況，相對於單redis節點來說，優點在於 防止了 單節點故障...
JDK類載入機制原始碼分析及原始碼分析
jvm的類載入機制主要有如下三種機制 1.全盤負責 所謂全盤負責，就是說當乙個類載入器載入個個class的時候，該class所依賴和引用的其他class也將由該類載入 器負責載入，除非使用另外乙個類載入器來載入。2.雙親委託 所謂雙親委託則是先讓parent 父 類載入器試圖載入該class 若父載...
MyBatis原始碼分析（三）批量更新
主要是org.apache.ibatis.executor.batchexecutor這個類，此類繼承baseexecutor 基本增刪改查，快取，懶載入處理 batchexecutor這個類有四個屬性 批處理更新最大返回結果 public static final int batch update...