去某國企養豬場面試一直沒訊息後，今天打電話過去諮詢，居然被掛了【臉黑】。

一定要吸取一個教訓：

大廠子不看你寫的專案經驗，但是很注重實習經歷！注意，實習很重要，一定要標註公司框架和專案用的工具！！！

去國企，簡歷一定要包裝！一定要包裝！一定要包裝！! ！

要金光閃閃！牛逼哄哄！然後又表現的上進積極！！國企就是眼高，不包裝不管面試多號妥妥掛！！！

1. http非冪等

冪等有以下的特性：操作次數N > 0的時候，GET | HEAD | PUT | DELETE 方法具有冪等性。sql中SELECT也是冪等操作。

GET方法用於獲取資源，不應有副作用，所以是冪等

DELETE方法用於刪除資源，有副作用，但它應該滿足冪等性

POST和PUT的區別容易被簡單地誤認為“POST表示建立資源，PUT表示更新資源”；而實際上，二者均可用於建立資源，更為本質的差別是在冪等性方面。

POST所對應的URI並非建立的資源本身，而是資源的接收者。不具有冪等性

2. redis特性

redis在資料插入請求commit時，會立即儲存在系統記憶體中，一段時間後將其儲存在硬碟介質中，則redis符合事務中__特性

redis事務在執行的過程中，不會處理其它命令，而是等所有命令都執行完後，再處理其它命令（滿足隔離性）;
redis事務在執行過程中發生錯誤或程序被終結，都能保證資料的(一致性)；
redis事務在執行的中途遇到錯誤，不會回滾，而是繼續執行後續命令；（違反原子性）

3. 網路連線處於close-wait狀態，則該節點處於

close_wait狀態出現的原因是被動關閉方未關閉socket造成

終止一個連線要經過4次握手。這由TCP的半關閉造成的。既然一個TCP連線是全雙工（即資料在兩個方向上能同時傳遞，可理解為兩個方向相反的獨立通道），因此每個方向必須單獨地進行關閉。

程序打開了socket，然後用派生子程序來處理業務，父程序繼續對網路請求進行監聽，永遠不會終止。客戶端發FIN過來的時候，處理業務的子程序的read返回0，子程序發現對端已經關閉了，直接呼叫close()對本端進行關閉。實際上，僅僅使socket的引用計數減1，socket並沒關閉。從而導致系統中又多了一個CLOSE_WAIT的socket

4.mysql事務的隔離級別

·未提交讀(Read Uncommitted)：允許髒讀，也就是可能讀取到其他會話中未提交事務修改的資料

·提交讀(Read Committed)：只能讀取到已經提交的資料。Oracle等多數資料庫預設都是該級別 (不重複讀)

·可重複讀(Repeated Read)：在同一個事務內的查詢都是事務開始時刻一致的，InnoDB預設級別。在SQL標準中，該隔離級別消除了不可重複讀，但是還存在幻象讀

·序列讀(Serializable)：完全序列化的讀，每次讀都需要獲得表級共享鎖，讀寫相互都會阻塞

5.定時任務

3.15 8-11 /2 * root run-parts /etc/cron.daily

表示日期、時間內，每隔兩個小時執行一次任務。

cron服務每分鐘不僅要讀一次/var/spool/cron內的所有檔案，還需要讀一次/etc/crontab，因此我們配置這個檔案也能運用cron服務做一些事情。

如果去掉run-parts引數的話，後面就可以寫要執行的某個指令碼名，而不是資料夾名了。

6. 設計模式

門面模式（facade）

提供一個統一的介面去訪問多個子系統的多個不同的介面，它為子系統中的一組介面提供一個統一的高層介面。使用子系統更容易使用。

//開燈
public class Light 
{
    public void open(){
        System.out.println("Light has been opened!");
    }
}

//熱水器
public class Heater 
{
    public void open(){
        System.out.println("Heater has been opened!");
    }
}

//同時開燈和熱水器，使用門面模式
public static void main()
{
    Ligth light = new light1();
    Light light = new light2();
    Heater heater = new Heater();

    light1.open();
    light2.open();
    heater.open();
}

介面卡模式（Adapter Pattern）

介面卡模式作為兩個不同介面的橋樑