Java面試寶典
CHAR和VARCHAR型別類似，但它們儲存和檢索的方式不同。它們的最大長度和是否尾部空格被保留等方面也不同。在儲存或檢索過程中不進行大小寫轉換。
CHAR和VARCHAR型別宣告的長度表示你想要儲存的最大字元數。例如，CHAR(30)可以佔用30個字元。
CHAR列的長度固定為建立表時宣告的長度。長度可以為從0到255的任何值。當儲存CHAR值時，在它們的右邊填充空格以達到指定的長度。當檢索到CHAR值時，尾部的空格被刪除掉。在儲存或檢索過程中不進行大小寫轉換。
VARCHAR列中的值為可變長字串。長度可以指定為0到65,535
同CHAR對比，VARCHAR值儲存時只儲存需要的字元數，另加一個位元組來記錄長度(如果列宣告的長度超過255，則使用兩個位元組)。
VARCHAR值儲存時不進行填充。當值儲存和檢索時尾部的空格仍保留，符合標準SQL。
如果分配給CHAR或VARCHAR列的值超過列的最大長度，則對值進行裁剪以使其適合。如果被裁掉的字元不是空格，則會產生一條警告。如果裁剪非空格字元，則會造成錯誤(而不是警告)並通過使用嚴格SQL模式禁用值的插入。參見
3.檢視JDK原始碼可知，String類equals方法的具體實現也是比較char[]陣列的值，那麼String字串是如何轉換為char陣列的呢？繼續追蹤原始碼看到內部呼叫的是一個原生方法：System.arraycopy，實現是C++。
具體參看：System.arraycopy原始碼分析、關於System.arrayCopy這兩篇文章中有比較詳細的分析和介紹。
4.以下內容引用自：overload和override的區別
override（重寫）
- 方法名、引數、返回值相同。
- 子類方法不能縮小父類方法的訪問許可權。
- 子類方法不能丟擲比父類方法更多的異常(但子類方法可以不丟擲異常)。
- 存在於父類和子類之間。
- 方法被定義為final不能被重寫。
引數型別、個數、順序至少有一個不相同。 不能過載只有返回值不同的方法名。 存在於父類和子類、同類中。
5.面向物件的基本特徵：封裝、繼承、多型，也可以加上抽象。參看：面向物件的三個基本特徵（講解）和面向物件的4個基本特徵
7.各種Map、List的區別：ArrayList、linklist、list的區別
- HashMap：可以存null鍵或值，非同步，同步的方式可以是手動加或者呼叫如下方法：Map Collections.synchronizedMap(Map m)
- Hashtable：不可以存null的鍵或值，同步處理，以上兩者詳細差異參見：http://oznyang.iteye.com/blog/30690
- TreeMap：預設按鍵值的升序排序，也可指定排序的比較器，當用Iterator遍歷TreeMap時，得到的記錄是排過序的
- LinkedHashMap：按記錄的插入順序排序，其遍歷速度只和實際資料有關，和容量無關，這點與HashMap相反，以上內容參考：http://sina.lt/h57
- ArrayList：是非同步的，且允許null值的元素
- LinkedList：同上，但提供額外的get，remove，insert方法在LinkedList的首部或尾部。這些操作使LinkedList可被用作堆疊（stack），佇列（queue）或雙向佇列（deque）
- Vecto：類似於ArrayList，但是同步的。這部分內容參考：http://www.blogjava.net/soufan/archive/2006/09/08/68565.html
- Stack：同上，繼承自Vector，實現一個後進先出的堆疊，其提供5個額外的方法使得Vector得以被當作堆疊使用，如push、pop、empty、search、peek等
8.Java程序間通訊：
先看看傳統的程序間通訊的手段有什麼，上面的各位都說了不少了，無外乎還是以下的這些手段：(1) 管道(PIPE) (2) 命名管道(FIFO) (3) 訊號燈(Semphore) (4) 訊息佇列(MessageQueue) (5) 共享記憶體(SharedMemory) (6) Socket(當然也有Socket)。如果加上上面提到的臨時檔案（臨時檔案其實是很難處理的，不同的程序間單靠臨時檔案可以互動資訊，但是做到程序的排程控制確是很費力的事情，當然也不是不能做到） 現在樓主的問題是JAVA如何支援程序間通訊。俺們把JAVA程序理解為JVM程序。很明顯，傳統的這些大部分技術是無法被俺們的應用程式利用了（這些程序間通訊都是靠系統呼叫來實現的）。但是JAVA也有很多方法可以進行程序間通訊的。 除了上面提到的Socket之外，當然首選的IPC可以使用RMI，或者CORBA也可以。其實JAVA的CORBA實現也是通過RMI來實現的，而RMI歸根結底也是靠Socket來實現的。 所以說JAVA程序間通訊的最基本手段是Socket也不為過。
以上內容引用自：java如何實現程序間的通訊?。更詳細的文章和程式碼參見： java多執行緒通訊方法、 程序間資料通訊方式和特點、 程序間通訊
9.SQL分組函式是什麼概念，具體有哪些？和單行函式不同的是，分組函式作用於一組記錄，每一組返回一個結果。這個組可以是整個表，也可以是有group by子句將表分成的多個組。常用的有：COUNT({*/[distinct/all]express})、AVG()、SUM()、MAX()、MIN()等
10.abstract方法是否可同時static、native、synchronizd：靜態方法可以被外部類或方法直接訪問而無需例項化，原生方法定義的具體實現交由JVM之外的程式語言，同步方法標識程式碼段需要做同步鎖處理因此必須有方法體
11.Java傳值還是傳引用？之前我以為我明白了，但是面試時被問到static方法引數是傳遞值的引用（ref）還是值（value）？這下我就懵了……
12.InnoDB與MyISAM的六大區別：
| MyISAM | InnoDB | |
| 構 成上的區別： | 每個MyISAM在磁碟上儲存成三個檔案。第一個 檔案的名字以表的名字開始，副檔名指出檔案型別。 .frm檔案儲存表定義。 資料檔案的擴 展名為.MYD (MYData)。 索引檔案的擴 展名是.MYI (MYIndex)。 |
基於磁碟的資源是InnoDB表空間資料檔案和它的日誌檔案，InnoDB表的 大小隻受限於作業系統檔案的大小，一般為2GB |
| 事務處理上方面: | MyISAM型別的表強調的是效能，其執行數 度比InnoDB型別更快，但是不提供事務支援 | InnoDB提供事務支援事務，外部鍵等高階 資料庫功能 |
| SELECT UPDATE,INSERT，Delete操 作 | 如果執行大量的SELECT，MyISAM是更好的選擇 | 1.如果你的資料執行大量的INSERT或UPDATE，出於效能方面的考慮，應該使用InnoDB表 2.DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的 刪除。 3.LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成MyISAM表，匯入資料後再改成InnoDB表，但是對於使用的額外的InnoDB特性（例如外來鍵）的表不適用 |
| 對AUTO_INCREMENT的 操作
|
每表一個AUTO_INCREMEN列的內部處理。 MyISAM為INSERT和UPDATE操 作自動更新這一列。這使得AUTO_INCREMENT列更快（至少10%）。在序列頂的值被刪除之後就不 能再利用。(當AUTO_INCREMENT列被定義為多列索引的最後一列， 可以出現重使用從序列頂部刪除的值的情況）。 AUTO_INCREMENT值可用ALTER TABLE或myisamch來重置 對於AUTO_INCREMENT型別的欄位，InnoDB中必須包含只有該欄位的索引，但 是在MyISAM表中，可以和其他欄位一起建立聯 合索引 更好和更快的auto_increment處理 |
如果你為一個表指定AUTO_INCREMENT列，在資料詞典裡的InnoDB表控制代碼包含一個名為自動增長計數 器的計數器，它被用在為該列賦新值。 自動增長計數 器僅被儲存在主記憶體中，而不是存在磁碟上 關於該計算器 的演算法實現，請參考 AUTO_INCREMENT列 在InnoDB裡 如何工作 |
| 表 的具體行數 | select count(*) from table,MyISAM只要簡單的讀出儲存好的行數，注意的是，當count(*)語句包含where條件時，兩種表的操作是一樣的 | InnoDB中不 儲存表的具體行數，也就是說，執行select count(*) from table時，InnoDB要掃描一遍整個表來計算有多少行 |
| 鎖 | 表鎖 | 提供行鎖(locking on row level)，提供與Oracle型別一致的不加鎖讀取(non-locking read in SELECTs)，另外，InnoDB表的行鎖也不是絕對的，如果在執 行一個SQL語句時MySQL不能確定要掃描的範圍，InnoDB表同樣會鎖全表，例如update table set num=1 where name like “%aaa%” |
13.string與stringbuffer的區別、StringBuilder與StringBuffer和String 的區別
14.騰訊資料結構題：快速尋找單鏈表的中間節點，給定兩個指標。參考：用標尺法快速找到單鏈表的中間結點
轉載於:https://my.oschina.net/cwalet/blog/139062