接著昨天的cache_flush，首先進入以此開頭的這個代碼塊
這個代碼塊主要是處理一些取消內存關系的cache節點，并預估需要重新分配的children大小。這里有一個先決條件是，cache是按child_id升序排序的，同樣children也是升序排序的。

從上面可以看出，如果是取消內存關系的cache節點，之前統計的cache節點數量sz就要減一。估計有些人會納悶為什么還要減一，畢竟當初統計節點數量的時候，就沒有把UNSET_MASK的cache節點算進去。這是因為sz的作用并不是用來表示節點的數量，而是表示children需要拓展的尺寸，由于標記UNSET_MASK的child要從children中刪除，那么children數組中就有空閑的位置，所以需要拓展的尺寸也就減少，sz就減一了。

再看
如果cache中的所有節點都是UNSET_MASK的話，就會跳到copy_next處，移動children的其他部分來填充被刪除的那些child_id。copy_next的代碼我就不貼了。

如果進入這個判斷，則說明cache中不全是UNSET_MASK節點，還包含添加新關系的節點存在。雖然這個判斷不直觀，但是鑒于他們都是升序排序的，這樣的判斷也就行得通了。

進入下面的代碼，就是利用上面計算出來的sz拓展children的時候了。
其中的link_expand就是拓展數組的地方，里面的實現基本上就是realloc，策略不同而已。
拓展之后，用移動內存的方式，在children數組中留個空缺，容納還沒有處理的cache節點?？杖币舻米銐虼?，搞不好剩下的cache節點都是添加的。

接下來有再進入一個代碼塊
這個while循環和上面講述的有點像，不過其任務不再是計算需要拓展的空間。
第1個if，仍舊是從children中刪除關系的。但是第2個if，則不再是一個break了
新添加的child_id，放到剛才拓展children時騰出來的空間中去，并保持children升序排序，這一點很重要。

剩下的代碼就沒什么了，就是復制child_id到children中，無論child_id來自children還是cache，總之要保證他們升序排序。

看起來，cache_flush是看完了。但是仍舊覺得這個函數無比爛，有太多的地方，需要用人類有限的處理能力去進行分析和維護。
明天，是應該看看之前那些暫時略過不看的代碼了。到這里為止，只是跟著程序一條分支看看而已，還有其他分支呢。