1.TCP 與 UDP 的區別，以及各自的用途
http://www.jianshu.com/notebooks/3194766/latest
http://www.jianshu.com/notebooks/3276500/latest
2.內存中的堆與棧到底是怎麼回事？.md
基本概念
棧區（Stack）：由編譯器自動分配釋放 ，存放函數的參數值，局部變量等，內存的分配是連續的，類似於數據結構中的棧。即，所分配的內存是在一塊連續的內存區域內．當我們聲明變量時，那麼編譯器會自動接着當前棧區的結尾來分配內存
堆區（Heap）：一般由程序員分配釋放， 若程序員不釋放，程序結束時可能由操作系統回收．類似於鏈表，在內存中的分佈不是連續的，它們是不同區域的內存塊通過指針鏈接起來的．一旦某一節點從鏈中斷開，我們要人爲的把所斷開的節點從內存中釋放
全局/靜態區（Static）：全局變量和靜態變量的存儲是放在一塊的，初始化的全局變量和靜態變量在一塊區域， 未初始化的全局變量和未初始化的靜態變量在相鄰的另一塊區域。 程序結束後由系統釋放
文字常量區：常量字符串就是放在這裏的。 程序結束後由系統釋放
程序代碼區：存放函數體的二進制代碼 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
靜態分配：程序編譯鏈接時分配的大小和使用壽命就已經確定
動態分配：在程序執行的過程中動態地分配或者回收存儲空間的分配內存的方法。動態內存分配不像數組等靜態內存分配方法那樣需要預先分配存儲空間，而是由系統根據程序的需要即時分配，且分配的大小就是程序要求的大小。
內存泄露：通常是程序自身編碼缺陷造成。用動態存儲分配函數動態開闢的空間，在使用完畢後未釋放，結果導致一直佔據該內存單元。直到程序結束。
內存碎片：是一個系統問題。描述系統中不可以用的空閒內存。由於空閒內存以小且不連續方式出現在不同的位置，導致空閒內存無法使用，這個與內存管理算法息息相關。
內部碎片：已經被分配出去（能明確指出屬於哪個進程）卻不能被利用的內存空間；
內部碎片產生原因：因爲所有的內存分配必須起始於可被 4、8 或 16 整除（視處理器體系結構而定）的地址或者因爲MMU的分頁機制的限制，決定內存分配算法僅能把預定大小的內存塊分配給客戶。假設當某個客戶請求一個 43 字節的內存塊時，因爲沒有適合大小的內存，所以它可能會獲得 44字節、48字節等稍大一點的字節，因此由所需大小四捨五入而產生的多餘空間就叫內部碎片。
外部碎片：指的是還沒有被分配出去（不屬於任何進程），但由於太小了無法分配給申請內存空間的新進程的內存空閒區域。
外部碎片產生原因：頻繁的分配與回收物理頁面會導致大量的、連續且小的頁面塊夾雜在已分配的頁面中間，就會產生外部碎片。如果一個進程申請了一個8個單位的內存空間，隨後便釋放了。後續進程申請的內存空間都大於8（比如是16，32等）。那麼這8個單位的空間永遠得不到使用，變成外部碎片。
理解到底放哪裏
int a = 0; //全局初始化區
char *p1; //全局未初始化區
main(){
int b; //棧
char s[] = "abc"; //棧
char *p2; //棧
char *p3 = "123456"; //123456\0在常量區，p3在棧上。
static int c =0； //全局（靜態）初始化區
p1 = (char *)malloc(10); //堆
p2 = (char *)malloc(20); //堆
}
堆內存與棧內存的區別
申請和回收方式不同：棧上的空間是自動分配自動回收的，所以棧上的數據的生存週期只是在函數的運行過程中，運行後就釋放掉，不可以再訪問。而堆上的數據只要程序員不釋放空間，就一直可以訪問到，不過缺點是一旦忘記釋放會造成內存泄露。
碎片問題：對於棧，不會產生不連續的內存塊；但是對於堆來說，不斷的new、delete勢必會產生上面所述的內部碎片和外部碎片。
申請大小的限制：棧是向低地址擴展的數據結構，是一塊連續的內存的區域。棧頂的地址和棧的最大容量是系統預先規定好的，如果申請的空間超過棧的剩餘空間，就會產生棧溢出；對於堆，是向高地址擴展的數據結構，是不連續的內存區域。堆的大小受限於計算機系統中有效的虛擬內存。由此可見，堆獲得的空間比較靈活，也比較大。
** 申請效率的比較**：棧由系統自動分配，速度較快。但程序員是無法控制的；堆：是由new分配的內存，一般速度比較慢，而且容易產生內存碎片,不過用起來最方便。
** 當然還有存儲內容的不一樣**
3.外觀設計模式：
Design Patterns in Swift：外觀模式
Facade設計模式
Facade設計模式爲多個子模塊或子系統提供統一的、單獨的API接口。使用時只需要使用高層接口即可，根本不需要了解此API底下複雜的子系統接口。
何時使用：
在設計初期，我們就應該有意識的將不同層之間進行分離，比如我們常用的MVC設計模式，就需要考慮在層與層之間建立外觀Facade。
在開發階段，可能由於業務要求或者重構，子系統越來越複雜、類越來越多，這時候再次調用子系統會變得很繁瑣，使用Facade提供一個簡單的接口是很有效的。
對於遺留的老系統，可能難以擴展和維護，但是包含很重要的功能，新的需求必須依賴它，這時候使用Facade也是很合適的。來爲遺留代碼建立一個新的Facade接口，新系統只要與Facade對象交互即可。
Facade優點：
Facade設計模式是容易實現和理解的，我們需要爲複雜的子模塊類提供一個簡單的接口，Facade類不應該暴露子模塊的實現細節。
Facade模式可以有效保證調用各個模塊功能的接口和你隱藏起來的實現模塊功能的邏輯代碼是一個鬆耦合的關係。同時也可以減少你的子系統或子模塊對外部代碼的依賴。
http://www.nowcoder.com/discuss/5949?type=0&order=0&pos=7&page=7
http://blog.csdn.net/see__you__again/article/details/51713703
java基礎面試題