場景
在應用層面上需要新增員工派近，刪除員工，修改員工以及查詢操作。
而負責給應用層提供接口的Core層將這些員工信息保存到文件里面渴频。
思路
回顧下映射IO和內(nèi)存池的應用
映射IO可以把一個文件映射到內(nèi)存上藏杖，通過操作這段內(nèi)存來達到修改文件的效果将塑。
而內(nèi)存池（在這里只說固定內(nèi)存池），就是一開始先分配一塊內(nèi)存蝌麸，當別人需要的時候就拿出一小塊內(nèi)存給別人用点寥。
首先Core層初始化的時候要得到文件路徑和結構體大小，然后用映射IO得到一塊內(nèi)存来吩，然后再把這段內(nèi)存作為內(nèi)存池來使用敢辩。
員工信息可以當作一個結構體，應用層需要新增員工的時候弟疆，Core層就分配這個結構體大小的內(nèi)存來給應用層戚长，從而達到將該員工寫入文件的效果。刪除也是類似怠苔。
還需要思考的問題
1.Core層加載文件時要知道哪些塊是已經(jīng)在用同廉，哪些塊還沒被使用，以及存儲的結構體大小。
因此文件除了需要存應用層存放的數(shù)據(jù)還需要額外的空間記錄別的信息迫肖。如圖锅劝。
2.當DATA塊已經(jīng)存滿了，需要擴充文件大小來存放新數(shù)據(jù)蟆湖。新擴充的那塊同樣需要額外的空間存放信息故爵。
考慮到存放的結構體都是固定大小的，因此UNIT_SIZE只需存放一次就好了隅津。同樣诬垂，每次文件擴充的大小也是固定的，每一塊能夠存放的單元個數(shù)也是固定的伦仍，COUNT只存一次就好了剥纷。
但是，即使這樣呢铆，DATA塊和DATA塊之間隔著一個STATUS塊晦鞋，這樣子可能出現(xiàn)內(nèi)存不對齊的問題。這個問題在當前這種設計下是不可避免的棺克。
設計
我最終的設計并沒有去解決內(nèi)存不對齊的問題悠垛，而是避開了該問題。如圖娜谊。
首先UNIT_SIZE和COUNT不是放在額外的空間确买，而是放在第一個DATA塊的第一個UNIT，而記錄DATA塊中每個UNIT的使用狀態(tài)的STATUS塊也不保存到文件纱皆，而是在Core層初始化的時候傳入應用層的寫的方法來判斷每一個UNIT的狀態(tài)湾趾。
其他
代碼在公司電腦上面，所以就先不貼代碼了派草。
寫的不好的地方可以評論指點下搀缠。
