基礎
- main方法可以使用final，synchronized修飾。
- java代碼的執行順序：父類靜態變量、父類靜態代碼塊、子類靜態變量、子類靜態代碼塊、父類非靜態變量、父類非靜態代碼塊、父類構造函數、子類非靜態變量、子類非靜態代碼塊、子類構造函數。
- 變量的類型：成員變量、靜態變量和局部變量。
- 構造函數：構造函數不能被繼承。當父類沒有提供無參數的構造函數時，子類構造函數必須顯式的調用父類的構造函數。普通方法也可以和class同名。
- clone：可以利用串行化來實現對象深層複製。
- 多態：指允許不同類的對象對同一消息做出響應。即同一消息可以根據發送對象的不同而採用多種不同的行爲方式。其存在的必要條件；要有繼承、要有重寫、父類引用指向子類對象。
內存泄漏
內存泄露的定義: 當某些對象不再被應用程序所使用,但是由於仍然被引用而導致垃圾收集器不能釋放(Remove,移除)他們.用白話來說就是: 該回收的內存沒被回收,最後因爲內存不夠用而導致程序報錯。
抽象與接口
- 一語法層次
在語法層次，java語言對於抽象類和接口分別給出了不同的定義。
抽象類方式中，抽象類可以擁有任意範圍的成員數據，同時也可以擁有自己的非抽象方法，但是接口方式中，它僅能夠有靜態、不能修改的成員數據（但是我們一般是不會在接口中使用成員數據），同時它所有的方法都必須是抽象的。在某種程度上來說，接口是抽象類的特殊化。
對子類而言，它只能繼承一個抽象類（這是java爲了數據安全而考慮的），但是卻可以實現多個接口。 - 二設計層次
上面只是從語法層次和編程角度來區分它們之間的關係，這些都是低層次的，要真正使用好抽象類和接口，我們就必須要從較高層次來區分了。只有從設計理念的角度才能看出它們的本質所在。一般來說他們存在如下三個不同點：
1、 抽象層次不同。抽象類是對類抽象，而接口是對行爲的抽象。抽象類是對整個類整體進行抽象，包括屬性、行爲，但是接口卻是對類局部（行爲）進行抽象。
2、 跨域不同。抽象類所跨域的是具有相似特點的類，而接口卻可以跨域不同的類。我們知道抽象類是從子類中發現公共部分，然後泛化成抽象類，子類繼承該父類即可，但是接口不同。實現它的子類可以不存在任何關係，共同之處。例如貓、狗可以抽象成一個動物類抽象類，具備叫的方法。鳥、飛機可以實現飛Fly接口，具備飛的行爲，這裏我們總不能將鳥、飛機共用一個父類吧！所以說抽象類所體現的是一種繼承關係，要想使得繼承關係合理，父類和派生類之間必須存在”is-a” 關係，即父類和派生類在概念本質上應該是相同的。對於接口則不然，並不要求接口的實現者和接口定義在概念本質上是一致的， 僅僅是實現了接口定義的契約而已。
3、 設計層次不同。對於抽象類而言，它是自下而上來設計的，我們要先知道子類才能抽象出父類，而接口則不同，它根本就不需要知道子類的存在，只需要定義一個規則即可，至於什麼子類、什麼時候怎麼實現它一概不知。比如我們只有一個貓類在這裏，如果你這是就抽象成一個動物類，是不是設計有點兒過度？我們起碼要有兩個動物類，貓、狗在這裏，我們在抽象他們的共同點形成動物抽象類吧！所以說抽象類往往都是通過重構而來的！但是接口就不同，比如說飛，我們根本就不知道會有什麼東西來實現這個飛接口，怎麼實現也不得而知，我們要做的就是事前定義好飛的行爲接口。所以說抽象類是自底向上抽象而來的，接口是自頂向下設計出來的。
IOC
控制反轉，本來對象是需要你的程序自己創建的，有了IOC你可以把不用再程序中手動new一個對象了，將創建對象的過程交個一個組件，這個組件去創建你需要的對象，你只需要從中獲得創建的對象，程序的所有對象都在這個組件中創建，如果你不需要程序的那一部分了，可以很用以刪除，而不影響程序其他部分。
事務
事務特性：原子性、一致性、隔離性、持久性。
A.Serializable（串行化）：一個事務在執行過程中完全看不到其他事務對數據庫所做的更新（事務執行的時候不允許別的事務併發執行。事務串行化執行，事務只能一個接着一個地執行，而不能併發執行。）。
B.Repeatable Read（可重複讀）：一個事務在執行過程中可以看到其他事務已經提交的新插入的記錄，但是不能看到其他其他事務對已有記錄的更新。
C.Read Commited（讀已提交數據）：一個事務在執行過程中可以看到其他事務已經提交的新插入的記錄，而且能看到其他事務已經提交的對已有記錄的更新。
D.Read Uncommitted（讀未提交數據）：一個事務在執行過程中可以看到其他事務沒有提交的新插入的記錄，而且能看到其他事務沒有提交的對已有記錄的更新。
cookie 和 session 的區別
1、cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。
2、cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙
考慮到安全應當使用session。
3、session會在一定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能
考慮到減輕服務器性能方面，應當使用COOKIE。
4、單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。
5、所以個人建議：
將登陸信息等重要信息存放爲SESSION
其他信息如果需要保留，可以放在COOKIE中
JVM 內存模型
http://www.cnblogs.com/dingyingsi/p/3760447.html
SQL注入的原理
SQL Injection：就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，
最終達到欺騙服務器執行惡意的SQL命令。
防止：
1.永遠不要信任用戶的輸入，要對用戶的輸入進行校驗，可以通過正則表達式，或限制長度，對單引號和雙”-“進行轉換等。
2.永遠不要使用動態拼裝SQL，可以使用參數化的SQL或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員權限的數據庫連接，爲每個應用使用單獨的權限有限的數據庫連接。
4.不要把機密信息明文存放，請加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出儘可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝，把異常信息存放在獨立的表中。
悲觀鎖和樂觀鎖
悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認爲別人會修改，
所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關係
型數據庫裏邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數據的時候都認爲別人不會修改，
所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號
等機制。樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量，像數據庫如果提供類似於
write_condition機制的其實都是提供的樂觀鎖。
兩種鎖各有優缺點，不可認爲一種好於另一種，像樂觀鎖適用於寫比較少的情況下，即衝突真的很少
發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生衝突，上層應用
會不斷的進行retry，這樣反倒是降低了性能，所以這種情況下用悲觀鎖就比較合適。