基本功
HTTP 請求的 GET 與 POST 方式的區別
GET和POST本質上就是TCP鏈接，並無差別。但是由於HTTP的規定和瀏覽器/服務器的限制，導致他們在應用過程中體現出一些不同。
GET和POST還有一個重大區別，簡單的說：
GET產生一個TCP數據包;
POST產生兩個TCP數據包。
長的說：
對於GET方式的請求，瀏覽器會把http header和data一併發送出去，服務器響應200(返回數據);
而對於POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok(返回數據)。
也就是說，GET只需要汽車跑一趟就把貨送到了，而POST得跑兩趟，第一趟，先去和服務器打個招呼“嗨，我等下要送一批貨來，你們打開門迎接我”，然後再回頭把貨送過去。
因爲POST需要兩步，時間上消耗的要多一點，看起來GET比POST更有效。因此Yahoo團隊有推薦用GET替換POST來優化網站性能。但這是一個坑!跳入需謹慎。爲什麼?
1. GET與POST都有自己的語義，不能隨便混用。
2. 據研究，在網絡環境好的情況下，發一次包的時間和發兩次包的時間差別基本可以無視。而在網絡環境差的情況下，兩次包的TCP在驗證數據包完整性上，有非常大的優點。
3. 並不是所有瀏覽器都會在POST中發送兩次包，Firefox就只發送一次。
session 與 cookie 區別
1:cookie數據存放在客戶的瀏覽器上(客戶端),session數據放
@1:cookie不是很安全,別人可以分析存放在本地的cookie並進行cookie 欺騙,如果主要考慮到安全應當使用session
@2:session會在一定時間內保存在服務器上.當訪問增多,會比較佔用你服務器的性能,如果主要考慮到減輕服務器性能方面,應當使用cookie
2:單個cookie在客戶端的限制是3K,就是說一個站點在客戶端存放的cookie不能3K
@3:將登陸信息等重要信息存放爲session;其他信息如果需要保留,可以放在 cookie 中
3:session不能區分路徑,同一個用戶在訪問一個網站期間,所有的session在任何一個地方都可以訪問到.而cookie中如果設置了路徑參數,那麼同一個網站中不同路徑下的cookie互相是訪問不到的.cookie只能是子路徑訪問父路徑設置的cookie
4.分析:
http是無狀態的協議,客戶每次讀取web頁面時,服務器都打開新的會話,而且服務器也不會自動維護客戶的上下文信息,那麼要怎麼才能實現網上商店中的購物車呢：
session就是一種保存上下文信息的機制,它是針對每一個用戶的,變量的值保存在服務器端,通過SessionID來區分不同的客 戶,session是以cookie或URL重寫 爲基礎的。
默認使用cookie來實現,系統會創造一個名爲JSESSIONID的輸出cookie，我 們叫做session cookie,以區分persistent cookie(我們通常所說的cookie)
注意session cookie是存儲於瀏覽器內存中的，並不是寫到硬盤上的，這也就是我們剛纔看到的JSESSIONID，我們通常情是看不到JSESSIONID的，但 是當我們把瀏覽器的cookie禁止後，web服務器會採用URL重寫的方式傳遞Sessionid,我們就可以在地址欄看到 sessionid=KWJHUG6JJM65HS2K6之類的字符串。
明白了原理，我們就可以很容易的分辨出persistent cookie和session cookie的區別了，網上那些關於兩者安全性的討論也就一目瞭然了，session cookie針對某一次會話而言，會話結束session cookie也就隨着消失了,而persistent cookie只是存在於客戶端硬盤上的一段文本(通常是加密的)，而且可能會遭到cookie欺騙以及針對cookie的跨站腳本攻擊,自然不如 session cookie安全了。
5:通常session cookie是不能跨窗口使用的,當你新開了一個瀏覽器窗口進入相同頁面時,系統會賦予你一個新的sessionid,這樣我們信息共享的目的就達不到了,此時我們可以先把sessionid保存在persistent cookie中,然後在新窗口中讀出來,就可以得到上一個窗口SessionID了,這樣通過session cookie和persistent cookie的結合我們就實現了跨窗口的session tracking()會話跟蹤)
session 分佈式處理
一。分佈式Session的幾種實現方式
1.基於數據庫的Session共享
2.基於NFS共享文件系統
3.基於memcached 的session，如何保證 memcached 本身的高可用性？
4. 基於resin/tomcat web容器本身的session複製機制
5. 基於TT/Redis 或 jbosscache 進行 session 共享。
6. 基於cookie 進行session共享
https://blog.csdn.net/u014352080/article/details/51764311
JDBC 流程
JDBC流程：
第一步：加載Driver類，註冊數據庫驅動；
第二步：通過DriverManager,使用url，用戶名和密碼建立連接(Connection)；
第三步：通過Connection，使用sql語句打開Statement對象；
第四步：執行語句，將結果返回resultSet；
第五步：對結果resultSet進行處理；
第六步：倒敘釋放資源resultSet-》preparedStatement-》connection。
MVC 設計思想
MVC應用程序總是由三個部分組成.Event(事件)導致Controller改變Model或View,或者同時改變兩者.只要Controller改變了Models的數據或者屬性，所有依賴的View都會自動更新.類似的,只要Controller改變了View，View會從潛在的Model中獲取數據來刷新自己 。
MVC模式是一個複雜的架構模式,其實現也顯得非常複雜,但多種設計模式結合在一起,使MVC模式的實現變得相對簡單易行.Views可以看作一棵樹,顯然可以用Composite Pattern來實現.Views和Models之間的關係可以用Observer Pattern體現.Controller控制Views的顯示,可以用Strategy Pattern實現.Model通常是一個調停者,可採用Mediator Pattern來實現.
equals 與 == 的區別
equals方法最初是在所有類的基類Object中進行定義的，源碼是
1
2
3
public boolean equals(Object obj) {
return (this == obj);
}
由equals的源碼可以看出這裏定義的equals與==是等效的（Object類中的equals沒什麼區別），不同的原因就在於有些類（像String、Integer等類）對equals進行了重寫，但是沒有對equals進行重寫的類（比如我們自己寫的類）就只能從Object類中繼承equals方法，其equals方法與==就也是等效的，除非我們在此類中重寫equals。
對equals重新需要注意五點：
1 自反性：對任意引用值X，x.equals(x)的返回值一定爲true；
2 對稱性：對於任何引用值x,y,當且僅當y.equals(x)返回值爲true時，x.equals(y)的返回值一定爲true；
3 傳遞性：如果x.equals(y)=true, y.equals(z)=true,則x.equals(z)=true ；
4 一致性：如果參與比較的對象沒任何改變，則對象比較的結果也不應該有任何改變；
5 非空性：任何非空的引用值X，x.equals(null)的返回值一定爲false 。
另外，"=="比"equals"運行速度快,因爲"=="只是比較引用。
————————————————