執行緒裡面有什麼是獨立的？

程序包含程式碼資料檔案，這個是程序內的所有執行緒共享，但是執行緒有自己的執行緒ID、程式計數器、暫存器和棧獨立的資源。

一個程序一定要有一個執行緒嗎？沒有執行緒的程序是什麼？

協程是什麼？

協程是線上程之上由“使用者”構建的併發單元，對OS來說無感知，協程的切換由使用者自己管理和排程。（這裡的使用者是相較於核心而言的，一些通用庫這裡也理解為使用者）

同步和互斥是怎麼做的？

執行緒間的同步和互斥是怎麼做的？

守護程序和殭屍程序，孤兒程序有什麼瞭解？

Linux Daemon（守護程序）是執行在後臺的一種特殊程序。它獨立於控制終端並且週期性地執行某種任務或等待處理某些發生的事件。它不需要使用者輸入就能執行而且提供某種服務，不是對整個系統就是對某個使用者程式提供服務。Linux系統的大多數伺服器就是通過守護程序實現的。常見的守護程序包括系統日誌程序syslogd、 web伺服器httpd、郵件伺服器sendmail和資料庫伺服器mysqld等。

守護程序一般在系統啟動時開始執行，除非強行終止，否則直到系統關機都保持執行。守護程序經常以超級使用者（root）許可權執行，因為它們要使用特殊的埠（1-1024）或訪問某些特殊的資源。

一個守護程序的父程序是init程序，因為它真正的父程序在fork出子程序後就先於子程序exit退出了，所以它是一個由init繼承的孤兒程序。守護程序是非互動式程式，沒有控制終端，所以任何輸出，無論是向標準輸出裝置stdout還是標準出錯裝置stderr的輸出都需要特殊處理。

守護程序的名稱通常以d結尾，比如sshd、xinetd、crond等

孤兒程序：一個父程序退出，而它的一個或多個子程序還在執行，那麼那些子程序將成為孤兒程序。孤兒程序將被init程序(程序號為1)所收養，並由init程序對它們完成狀態收集工作。

殭屍程序：一個程序使用fork建立子程序，如果子程序退出，而父程序並沒有呼叫wait或waitpid獲取子程序的狀態資訊，那麼子程序的程序描述符仍然儲存在系統中。這種程序稱之為僵死程序。

系統出現殭屍程序，為什麼產生和怎麼解決？

軟連線和硬連線瞭解嗎？硬連線和軟連線刪了，原物件會如何？

硬連線和軟連線的底層原理？ Inode是什麼？

強型別和弱型別，靜態型別動態型別是什麼？

TCP/UDP的瞭解？Tcp和udp的使用場景？Tcp的time_wait

Tcp粘包

TCP斷包就是因為最大報文段長度的存在，當訊息長度過大，，那麼tcp就會將其分片，然後每片被tcp封裝，然後由ip封裝，最後被傳輸到接收端，這樣子當接收端接收到訊息後，就會不清楚這是不是一個完整的訊息。

粘包則是因為為了提高網路利用率，當傳輸層發現傳輸的資料長度太小時，會等待多個訊息一起傳送，這時候就會提高網路利用率，但是當接收端接收過以後，會不知道這是一個完整的訊息，還是多個訊息在一起。從而有可能將其作為一個訊息來處理。nagle演算法就是實現的這個功能。

對於斷包和粘包的通常處理方法為將訊息封裝為一定的格式，例如每個訊息頭部為aa，尾部為55，或者將整個訊息的有效長度標明，這樣子當接收端接收到訊息之後，就可以以此來分辨訊息是不是我完整的。

而對於斷包和粘包的通常處理方法為將訊息封裝為一定的格式，例如每個訊息頭部為aa，尾部為55，或者將整個訊息的有效長度標明，這樣子當接收端接收到訊息之後，就可以以此來分辨訊息是不是我完整的。

**什麼是粘包現象？**TCP粘包是指傳送方傳送的若干包資料到接收方接收時粘成一包，從接收緩衝區看，後一包資料的頭緊接著前一包資料的尾。
為什麼出現粘包現象？
　　（1）傳送方原因
　　我們知道，TCP預設會使用Nagle演算法。而Nagle演算法主要做兩件事：1）只有上一個分組得到確認，才會傳送下一個分組；2）收集多個小分組，在一個確認到來時一起傳送。所以，正是Nagle演算法造成了傳送方有可能造成粘包現象。
　　（2）接收方原因。TCP接收到分組時，並不會立刻送至應用層處理，或者說，應用層並不一定會立即處理；實際上，TCP將收到的分組儲存至接收快取裡，然後應用程式主動從快取裡讀收到的分組。這樣一來，如果TCP接收分組的速度大於應用程式讀分組的速度，多個包就會被存至快取，應用程式讀時，就會讀到多個首尾相接粘到一起的包。
什麼時候需要處理粘包現象
（1）如果傳送方傳送的多個分組本來就是同一個資料的不同部分，比如一個很大的檔案被分成多個分組傳送，這時，當然不需要處理粘包的現象；
（2）但如果多個分組本毫不相干，甚至是並列的關係，我們就一定要處理粘包問題了。比如，我當時要接收的每個分組都是一個有固定格式的商品資訊，如果不處理粘包問題，每個讀進來的分組我只會處理最前邊的那個商品，後邊的就會被丟棄。這顯然不是我要的結果。
如何處理粘包現象
1）傳送方：對於傳送方造成的粘包現象，我們可以通過關閉Nagle演算法來解決，使用TCP_NODELAY選項來關閉Nagle演算法。
（2）接收方 遺憾的是TCP並沒有處理接收方粘包現象的機制，我們只能在應用層進行處理。
（3）應用層處理：應用層的處理簡單易行！並且不僅可以解決接收方造成的粘包問題，還能解決傳送方造成的粘包問題。

解決方法就是迴圈處理：應用程式在處理從快取讀來的分組時，讀完一條資料時，就應該迴圈讀下一條資料，直到所有的資料都被處理；但是如何判斷每條資料的長度呢？

　　兩種途徑：

　　　　1）格式化資料：每條資料有固定的格式（開始符、結束符），這種方法簡單易行，但選擇開始符和結束符的時候一定要注意每條資料的內部一定不能出現開始符或結束符；

　　　　2）傳送長度：傳送每條資料的時候，將資料的長度一併傳送，比如可以選擇每條資料的前4位是資料的長度，應用層處理時可以根據長度來判斷每條資料的開始和結束。

(18) http1.0和1.1有什麼區別

(19) https協議？原理？端到端中間的過程。

(20) 對稱加密和非對稱加密？

(21) Cookies和session的關係

(22) Cookies的最大儲存時間

(23) Mysql索引的原理，底層是怎麼存的？

(24) 主鍵和唯一鍵有什麼區別？

(25) Varchar和char的區別？

(26) UTF-8下面varchar能佔多少字元？GBK呢？

(27) 說下你知道的排序，比較一下他們的優缺點，複雜度和應用場景。