1、在Java中如何使用execute()、executeQuery()、executeUpdate()三個(gè)方法？
execute(String sql)

      執(zhí)行給定的 SQL 語句，該語句可能返回多個(gè)結(jié)果。

executeQuery(String sql)

      執(zhí)行給定的 SQL 語句，該語句返回單個(gè) ResultSet 對(duì)象

executeUpdate(String sql)

      執(zhí)行給定 SQL 語句，該語句可能為 INSERT、UPDATE 或 DELETE 語句，或者不返回任何內(nèi)容的 SQL 語句（如 SQL DDL 語句）

頭2種一般在查詢中使用

最后一個(gè)在插入、更新、刪除時(shí)使用

2、executeQuery()是干什么用的?實(shí)現(xiàn)什么功能??？
使用JDBC連接數(shù)據(jù)庫需要四步，第一步加載驅(qū)動(dòng)程序；第二步，連接數(shù)據(jù)庫；第三步，訪問數(shù)據(jù)庫；第四步，執(zhí)行查詢；其中在第四步執(zhí)行查詢時(shí)，要用statement類的executeQuery()方法來下達(dá)select指令以查詢數(shù)據(jù)庫，executeQuery()方法會(huì)把數(shù)據(jù)庫響應(yīng)的查詢結(jié)果存放在ResultSet類對(duì)象中供我們使用。即語句：String sql="select * from"+tableName; ResultSet rs=s.executeQuery(sql);

3、executeQuery、executeUpdate或execute方法區(qū)別？
在用純JSP做一個(gè)頁面報(bào)警功能的時(shí)候習(xí)慣性的用executeQuery來執(zhí)行SQL語句，結(jié)果執(zhí)行update時(shí)就遇到問題，語句能執(zhí)行，但返回結(jié)果出現(xiàn)問題，另外還忽略了executeUpdate的返回值不是結(jié)果集ResultSet,而是數(shù)值！特收藏如下一篇文章（感謝網(wǎng)友們對(duì)各種信息的貢獻(xiàn)）：

JDBCTM中Statement接口提供的execute、executeQuery和executeUpdate之間的區(qū)別

Statement 接口提供了三種執(zhí)行 SQL 語句的方法：executeQuery、executeUpdate 和 execute。使用哪一個(gè)方法由 SQL 語句所產(chǎn)生的內(nèi)容決定。

方法executeQuery
用于產(chǎn)生單個(gè)結(jié)果集的語句，例如 SELECT 語句。 被使用最多的執(zhí)行 SQL 語句的方法是 executeQuery。這個(gè)方法被用來執(zhí)行 SELECT 語句，它幾乎是使用最多的 SQL 語句。

方法executeUpdate
用于執(zhí)行 INSERT、UPDATE 或 DELETE 語句以及 SQL DDL（數(shù)據(jù)定義語言）語句，例如 CREATE TABLE 和 DROP TABLE。INSERT、UPDATE 或 DELETE 語句的效果是修改表中零行或多行中的一列或多列。executeUpdate 的返回值是一個(gè)整數(shù)，指示受影響的行數(shù)（即更新計(jì)數(shù)）。對(duì)于 CREATE TABLE 或 DROP TABLE 等不操作行的語句，executeUpdate 的返回值總為零。

使用executeUpdate方法是因?yàn)樵?createTableCoffees 中的 SQL 語句是 DDL （數(shù)據(jù)定義語言）語句。創(chuàng)建表，改變表，刪除表都是 DDL 語句的例子，要用 executeUpdate 方法來執(zhí)行。你也可以從它的名字里看出，方法 executeUpdate 也被用于執(zhí)行更新表 SQL 語句。實(shí)際上，相對(duì)于創(chuàng)建表來說，executeUpdate 用于更新表的時(shí)間更多，因?yàn)楸碇恍枰獎(jiǎng)?chuàng)建一次，但經(jīng)常被更新。

方法execute：
用于執(zhí)行返回多個(gè)結(jié)果集、多個(gè)更新計(jì)數(shù)或二者組合的語句。因?yàn)槎鄶?shù)程序員不會(huì)需要該高級(jí)功能

execute方法應(yīng)該僅在語句能返回多個(gè)ResultSet對(duì)象、多個(gè)更新計(jì)數(shù)或ResultSet對(duì)象與更新計(jì)數(shù)的組合時(shí)使用。當(dāng)執(zhí)行某個(gè)已存儲(chǔ)過程 或動(dòng)態(tài)執(zhí)行未知 SQL 字符串（即應(yīng)用程序程序員在編譯時(shí)未知）時(shí)，有可能出現(xiàn)多個(gè)結(jié)果的情況，盡管這種情況很少見。
因?yàn)榉椒?execute 處理非常規(guī)情況，所以獲取其結(jié)果需要一些特殊處理并不足為怪。例如，假定已知某個(gè)過程返回兩個(gè)結(jié)果集，則在使用方法 execute 執(zhí)行該過程后，必須調(diào)用方法 getResultSet 獲得第一個(gè)結(jié)果集，然后調(diào)用適當(dāng)?shù)?getXXX 方法獲取其中的值。要獲得第二個(gè)結(jié)果集，需要先調(diào)用 getMoreResults 方法，然后再調(diào)用 getResultSet 方法。如果已知某個(gè)過程返回兩個(gè)更新計(jì)數(shù)，則首先調(diào)用方法 getUpdateCount，然后調(diào)用 getMoreResults，并再次調(diào)用 getUpdateCount。
對(duì)于不知道返回內(nèi)容，則情況更為復(fù)雜。如果結(jié)果是 ResultSet 對(duì)象，則方法 execute 返回 true；如果結(jié)果是 Java int，則返回 false。如果返回 int，則意味著結(jié)果是更新計(jì)數(shù)或執(zhí)行的語句是 DDL 命令。在調(diào)用方法 execute 之后要做的第一件事情是調(diào)用 getResultSet 或 getUpdateCount。調(diào)用方法 getResultSet 可以獲得兩個(gè)或多個(gè) ResultSet 對(duì)象中第一個(gè)對(duì)象；或調(diào)用方法 getUpdateCount 可以獲得兩個(gè)或多個(gè)更新計(jì)數(shù)中第一個(gè)更新計(jì)數(shù)的內(nèi)容。
當(dāng) SQL 語句的結(jié)果不是結(jié)果集時(shí)，則方法 getResultSet 將返回 null。這可能意味著結(jié)果是一個(gè)更新計(jì)數(shù)或沒有其它結(jié)果。在這種情況下，判斷 null 真正含義的唯一方法是調(diào)用方法 getUpdateCount，它將返回一個(gè)整數(shù)。這個(gè)整數(shù)為調(diào)用語句所影響的行數(shù)；如果為 -1 則表示結(jié)果是結(jié)果集或沒有結(jié)果。如果方法 getResultSet 已返回 null（表示結(jié)果不是 ResultSet 對(duì)象），則返回值 -1 表示沒有其它結(jié)果。也就是說，當(dāng)下列條件為真時(shí)表示沒有結(jié)果（或沒有其它結(jié)果）：

((stmt.getResultSet() == null) && (stmt.getUpdateCount() == -1))

如果已經(jīng)調(diào)用方法 getResultSet 并處理了它返回的 ResultSet 對(duì)象，則有必要調(diào)用方法 getMoreResults 以確定是否有其它結(jié)果集或更新計(jì)數(shù)。如果 getMoreResults 返回 true，則需要再次調(diào)用 getResultSet 來檢索下一個(gè)結(jié)果集。如上所述，如果 getResultSet 返回 null，則需要調(diào)用 getUpdateCount 來檢查 null 是表示結(jié)果為更新計(jì)數(shù)還是表示沒有其它結(jié)果。

當(dāng) getMoreResults 返回 false 時(shí)，它表示該 SQL 語句返回一個(gè)更新計(jì)數(shù)或沒有其它結(jié)果。因此需要調(diào)用方法 getUpdateCount 來檢查它是哪一種情況。在這種情況下，當(dāng)下列條件為真時(shí)表示沒有其它結(jié)果：

((stmt.getMoreResults() == false) && (stmt.getUpdateCount() == -1))

下面的代碼演示了一種方法用來確認(rèn)已訪問調(diào)用方法 execute 所產(chǎn)生的全部結(jié)果集和更新計(jì)數(shù)：

stmt.execute(queryStringWithUnknownResults);
while (true) {
int rowCount = stmt.getUpdateCount();
if (rowCount > 0) { // 它是更新計(jì)數(shù)
System.out.println("Rows changed = " + count);
stmt.getMoreResults();

　　在傳統(tǒng)的Java應(yīng)用中，Bean的生命周期非常簡(jiǎn)單。Java的關(guān)鍵詞new用來實(shí)例化Bean（或許他是非序列化的）。這樣就夠用了。相反，Bean 的生命周期在spring容器中更加細(xì)致。理解Spring Bean的生命周期非常重要，因?yàn)槟慊蛟S要利用Spring提供的機(jī)會(huì)來訂制Bean的創(chuàng)建過程。

1.容器尋找Bean的定義信息并且將其實(shí)例化。

2.使用依賴注入，Spring按照Bean定義信息配置Bean的所有屬性。

3.如果Bean實(shí)現(xiàn)了BeanNameAware接口，工廠調(diào)用Bean的setBeanName()方法傳遞Bean的ID。

4.如果Bean實(shí)現(xiàn)了BeanFactoryAware接口，工廠調(diào)用setBeanFactory()方法傳入工廠自身。

5.如果BeanPostProcessor和Bean關(guān)聯(lián)，那么它們的postProcessBeforeInitialzation()方法將被調(diào)用。

6.如果Bean指定了init-method方法，它將被調(diào)用。

7.最后，如果有BeanPsotProcessor和Bean關(guān)聯(lián)，那么它們的postProcessAfterInitialization()方法將被調(diào)用。

　　到這個(gè)時(shí)候，Bean已經(jīng)可以被應(yīng)用系統(tǒng)使用了，并且將被保留在Bean Factory中知道它不再需要。有兩種方法可以把它從Bean Factory中刪除掉。

1.如果Bean實(shí)現(xiàn)了DisposableBean接口，destory()方法被調(diào)用。

2.如果指定了訂制的銷毀方法，就調(diào)用這個(gè)方法。

　　Bean在Spring應(yīng)用上下文的生命周期與在Bean工廠中的生命周期只有一點(diǎn)不同，唯一不同的是，如果Bean實(shí)現(xiàn)了ApplicationContextAwre接口，setApplicationContext()方法被調(diào)用。

　　MySQL Hash索引結(jié)構(gòu)的特殊性，其檢索效率非常高，索引的檢索可以一次定位，不像B-Tree 索引需要從根節(jié)點(diǎn)到枝節(jié)點(diǎn)，最后才能訪問到頁節(jié)點(diǎn)這樣多次的IO訪問，所以 Hash 索引的查詢效率要遠(yuǎn)高于 B-Tree 索引。
　　可能很多人又有疑問了，既然 Hash 索引的效率要比 B-Tree 高很多，為什么大家不都用 Hash 索引而還要使用 B-Tree 索引呢？任何事物都是有兩面性的，Hash 索引也一樣，雖然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也帶來了很多限制和弊端，主要有以下這些。
（1）MySQL Hash索引僅僅能滿足"=","IN"和"< >"查詢，不能使用范圍查詢。
由于 MySQL Hash索引比較的是進(jìn)行 Hash 運(yùn)算之后的 Hash 值，所以它只能用于等值的過濾，不能用于基于范圍的過濾，因?yàn)榻?jīng)過相應(yīng)的 Hash 算法處理之后的 Hash 值的大小關(guān)系，并不能保證和Hash運(yùn)算前完全一樣。
（2）MySQL Hash索引無法被用來避免數(shù)據(jù)的排序操作。
由于 MySQL Hash索引中存放的是經(jīng)過 Hash 計(jì)算之后的 Hash 值，而且Hash值的大小關(guān)系并不一定和 Hash 運(yùn)算前的鍵值完全一樣，所以數(shù)據(jù)庫無法利用索引的數(shù)據(jù)來避免任何排序運(yùn)算；
（3）MySQL Hash索引不能利用部分索引鍵查詢。
對(duì)于組合索引，Hash 索引在計(jì)算 Hash 值的時(shí)候是組合索引鍵合并后再一起計(jì)算 Hash 值，而不是多帶帶計(jì)算 Hash 值，所以通過組合索引的前面一個(gè)或幾個(gè)索引鍵進(jìn)行查詢的時(shí)候，Hash 索引也無法被利用。
（4）MySQL Hash索引在任何時(shí)候都不能避免表掃描。
前面已經(jīng)知道，Hash 索引是將索引鍵通過 Hash 運(yùn)算之后，將 Hash運(yùn)算結(jié)果的 Hash 值和所對(duì)應(yīng)的行指針信息存放于一個(gè) Hash 表中，由于不同索引鍵存在相同 Hash 值，所以即使取滿足某個(gè) Hash 鍵值的數(shù)據(jù)的記錄條數(shù)，也無法從 Hash 索引中直接完成查詢，還是要通過訪問表中的實(shí)際數(shù)據(jù)進(jìn)行相應(yīng)的比較，并得到相應(yīng)的結(jié)果。
（5）MySQL Hash索引遇到大量Hash值相等的情況后性能并不一定就會(huì)比B-Tree索引高。
對(duì)于選擇性比較低的索引鍵，如果創(chuàng)建 Hash 索引，那么將會(huì)存在大量記錄指針信息存于同一個(gè) Hash 值相關(guān)聯(lián)。這樣要定位某一條記錄時(shí)就會(huì)非常麻煩，會(huì)浪費(fèi)多次表數(shù)據(jù)的訪問，而造成整體性能低下。

單例的特點(diǎn)：

1、保證某類只存在唯一實(shí)例。
2、該類本身完成自身的初始化。
3、獲取該唯一實(shí)例的方式非常明確，可以通過該類本身定義的靜態(tài)方法getInstance()獲取該類的唯一實(shí)例引用。

靜態(tài)變量定義某類的實(shí)例引用特點(diǎn)：
1、該類的實(shí)例引用的靜態(tài)變量可定義在任何文檔類當(dāng)中。
2、獲取該類的實(shí)例引用的靜態(tài)變量，可以通過定義該靜態(tài)變量的類名通過點(diǎn)語法進(jìn)行訪問該引用。
3、任何位置可以對(duì)該靜態(tài)變量進(jìn)行重新賦值。

　　通過這兩者方式的特點(diǎn)，我們可以很明顯的看出兩者之間的區(qū)別。（這一切都是基于某類只需要存在一個(gè)實(shí)例對(duì)象的前提來討論）
首先靜態(tài)變量方式不能確保某類的實(shí)例的唯一性，這樣在項(xiàng)目中，可能因?yàn)樵谀硞€(gè)文檔類中對(duì)該靜態(tài)變量進(jìn)行再次賦值，存不可意料的風(fēng)險(xiǎn)（這種風(fēng)險(xiǎn)可以規(guī)避）。同樣的，因?yàn)殪o態(tài)變量的定義的位置不確定，所以需要協(xié)議商定，這些靜態(tài)變量分類別進(jìn)行定義在一個(gè)固定的位置（比如說某個(gè)專門存放靜態(tài)變量方式的某類的對(duì)象的引用的文檔類當(dāng)中）。
　　而單例模式也就是靜態(tài)變量方式創(chuàng)建一個(gè)類的實(shí)例引用所帶來的缺陷的改善。首先解決引用的唯一實(shí)例可能被重新賦值的問題，單例模式中的getInstance()靜態(tài)方法實(shí)現(xiàn)時(shí)，采用懶漢式創(chuàng)建一個(gè)對(duì)象（當(dāng)然這只是創(chuàng)建方式的一種），規(guī)避了這一風(fēng)險(xiǎn)，無則創(chuàng)建，有則跳過創(chuàng)建。其次，getInstance()靜態(tài)方法定義在該類的內(nèi)部，獲取該類對(duì)象的引用位置非常明確，無需額外的溝通商定，團(tuán)隊(duì)成員拿起即用。最后一個(gè)區(qū)別并不是很明顯，聲明一個(gè)靜態(tài)變量，實(shí)際上，我們會(huì)直接對(duì)其進(jìn)行初始化賦值，這樣，在內(nèi)存占用上，所占用的內(nèi)存為該初始化賦值對(duì)象實(shí)際的內(nèi)存。而單例模式可以通過懶漢創(chuàng)建法延遲該內(nèi)存的占用，要知道，當(dāng)一個(gè)靜態(tài)變量只進(jìn)行聲明，而不進(jìn)行初始化時(shí)，實(shí)際的內(nèi)存占用只有4個(gè)字節(jié)（筆者個(gè)人推測(cè)，這四個(gè)字節(jié)只是一個(gè)指針地址所占用的內(nèi)存空間）。

HashMap/HashTable初始容量大小和每次擴(kuò)充容量大小的不同

可以看到HashTable默認(rèn)的初始大小為11，之后每次擴(kuò)充為原來的2n+1。HashMap默認(rèn)的初始化大小為16，之后每次擴(kuò)充為原來的2倍。還有我沒列出代碼的一點(diǎn)，就是如果在創(chuàng)建時(shí)給定了初始化大小，那么HashTable會(huì)直接使用你給定的大小，而HashMap會(huì)將其擴(kuò)充為2的冪次方大小。

也就是說HashTable會(huì)盡量使用素?cái)?shù)、奇數(shù)。而HashMap則總是使用2的冪作為哈希表的大小。我們知道當(dāng)哈希表的大小為素?cái)?shù)時(shí)，簡(jiǎn)單的取模哈希的結(jié)果會(huì)更加均勻（具體證明，見這篇文章），所以單從這一點(diǎn)上看，HashTable的哈希表大小選擇，似乎更高明些。但另一方面我們又知道，在取模計(jì)算時(shí)，如果模數(shù)是2的冪，那么我們可以直接使用位運(yùn)算來得到結(jié)果，效率要大大高于做除法。所以從hash計(jì)算的效率上，又是HashMap更勝一籌。

所以，事實(shí)就是HashMap為了加快hash的速度，將哈希表的大小固定為了2的冪。當(dāng)然這引入了哈希分布不均勻的問題，所以HashMap為解決這問題，又對(duì)hash算法做了一些改動(dòng)。具體我們來看看，在獲取了key對(duì)象的hashCode之后，HashTable和HashMap分別是怎樣將他們hash到確定的哈希桶（Entry數(shù)組位置）中的。

正如我們所言，HashMap由于使用了2的冪次方，所以在取模運(yùn)算時(shí)不需要做除法，只需要位的與運(yùn)算就可以了。但是由于引入的hash沖突加劇問題，HashMap在調(diào)用了對(duì)象的hashCode方法之后，又做了一些位運(yùn)算在打散數(shù)據(jù)。關(guān)于這些位計(jì)算為什么可以打散數(shù)據(jù)的問題，本文不再展開了。感興趣的可以看這里。

HashMap是支持null鍵和null值的，而HashTable在遇到null時(shí)，會(huì)拋出NullPointerException異常。

這并不是因?yàn)镠ashTable有什么特殊的實(shí)現(xiàn)層面的原因?qū)е虏荒苤С謓ull鍵和null值，這僅僅是因?yàn)镠ashMap在實(shí)現(xiàn)時(shí)對(duì)null做了特殊處理，將null的hashCode值定為了0，從而將其存放在哈希表的第0個(gè)bucket中。

1：先將top.jsp中的java腳本和jsp指令都執(zhí)行完畢以后再將top.jsp頁面加入到引用頁面中。

2：<%@ include file="top.jsp"%>靜態(tài)讀?。簞t是將top.jsp的整個(gè)頁面不加解析（無論是腳本還是指令）統(tǒng)統(tǒng)讀入到引用頁面中，然后和引用頁面一起進(jìn)行解析（即開始執(zhí)行腳本和指令）。

3：區(qū)別：其實(shí)上邊的兩條就是區(qū)別，但是需要注意的是用<%@ include file=""%>的時(shí)候被引用頁面中不能再出現(xiàn)其他網(wǎng)頁標(biāo)簽和page指令了，否則會(huì)沖突的

（jsp:include page=""）

父頁面和包含進(jìn)來的頁面多帶帶編譯，多帶帶翻譯成servlet后，在前臺(tái)拼成一個(gè)HTML頁面。

（%@include file=""%）

父頁面和包含進(jìn)來的頁面，代碼合并后，才一起翻譯成servlet，反饋到前臺(tái)，形成一個(gè)HTML頁面。

由此我們知道：jsp頁面是把include指令元素（<%@ include file=""%>）所指定的頁面的實(shí)際內(nèi)容（也就是代碼段）加入到引入它的jsp頁面中,合成一個(gè)文件后被jsp容器將它轉(zhuǎn)化成servlet?？梢钥吹竭@時(shí)會(huì)產(chǎn)生一個(gè)臨時(shí)class文件和一個(gè)servlet源文件。而動(dòng)作元素（）是在請(qǐng)求處理階段引入的，會(huì)被JSP容器生成兩個(gè)臨時(shí)class文件和兩個(gè)servlet原文件。而引入的只是servlet的輸出結(jié)果，即JspWriter對(duì)象的輸出結(jié)果，而不是jsp的源代碼。

java是在服務(wù)器端運(yùn)行的代碼，jsp在服務(wù)器的servlet里運(yùn)行，而javascript和html都是在瀏覽器端運(yùn)行的代碼。所以加載執(zhí)行順序是是java>jsp>js。

所有的JSP都會(huì)在客戶端發(fā)出請(qǐng)求后被容器轉(zhuǎn)譯成servlet的源代碼（java），然后再將源碼（java）編譯成servlet的類（class），放入到內(nèi)存里面。

1.可重入鎖

如果鎖具備可重入性，則稱作為可重入鎖。

像Synchronized和ReentrantLock都是可重入鎖，可重入性在我看來實(shí)際上表明了鎖的分配機(jī)制：

基于線程的分配，而不是基于方法調(diào)用的分配。

舉個(gè)簡(jiǎn)單的例子，當(dāng)一個(gè)線程執(zhí)行到某個(gè)Synchronized方法時(shí)，比如說method1，而在method1中會(huì)調(diào)用另外一個(gè)Synchronized方法method2，此時(shí)線程不必重新去申請(qǐng)鎖，而是可以直接執(zhí)行方法method2。

class MyClass {
    public synchronized void method1() {
        method2();
    }
     
    public synchronized void method2() {
         
    }
}

上述代碼中的兩個(gè)方法method1和method2都用Synchronized修飾了。

假如某一時(shí)刻，線程A執(zhí)行到了method1，此時(shí)線程A獲取了這個(gè)對(duì)象的鎖，而由于method2也是Synchronized方法，假如Synchronized不具備可重入性，此時(shí)線程A需要重新申請(qǐng)鎖。

但是這就會(huì)造成一個(gè)問題，因?yàn)榫€程A已經(jīng)持有了該對(duì)象的鎖，而又在申請(qǐng)獲取該對(duì)象的鎖，這樣就會(huì)線程A一直等待永遠(yuǎn)不會(huì)獲取到的鎖。

而由于Synchronized和Lock都具備可重入性，所以不會(huì)發(fā)生上述現(xiàn)象。

2.可中斷鎖

可中斷鎖：顧名思義，就是可以響應(yīng)中斷的鎖。

在Java中，Synchronized就不是可中斷鎖，而Lock是可中斷鎖。

如果某一線程A正在執(zhí)行鎖中的代碼，另一線程B正在等待獲取該鎖，可能由于等待時(shí)間過長，線程B不想等待了，想先處理其他事情，我們可以讓它中斷自己或者在別的線程中中斷它，這種就是可中斷鎖。

在前面演示LockInterruptibly()的用法時(shí)已經(jīng)體現(xiàn)了Lock的可中斷性。

3.公平鎖

公平鎖即盡量以請(qǐng)求鎖的順序來獲取鎖。比如同是有多個(gè)線程在等待一個(gè)鎖，當(dāng)這個(gè)鎖被釋放時(shí)，等待時(shí)間最久的線程（最先請(qǐng)求的線程）會(huì)獲得該所，這種就是公平鎖。

非公平鎖即無法保證鎖的獲取是按照請(qǐng)求鎖的順序進(jìn)行的。這樣就可能導(dǎo)致某個(gè)或者一些線程永遠(yuǎn)獲取不到鎖。

在Java中，Synchronized就是非公平鎖，它無法保證等待的線程獲取鎖的順序。

而對(duì)于ReentrantLock和ReentrantReadWriteLock，它默認(rèn)情況下是非公平鎖，但是可以設(shè)置為公平鎖。這一點(diǎn)由構(gòu)造函數(shù)可知：

public ReentrantLock() {
        sync = new NonfairSync();
    }


    public ReentrantLock(boolean fair) {
        sync = (fair)? new FairSync() : new NonfairSync();
    }

在ReentrantLock中定義了2個(gè)靜態(tài)內(nèi)部類，一個(gè)是NotFairSync，一個(gè)是FairSync，分別用來實(shí)現(xiàn)非公平鎖和公平鎖。

我們可以在創(chuàng)建ReentrantLock對(duì)象時(shí)，通過知道布爾參數(shù)來決定使用非公平鎖還是公平鎖。

如果參數(shù)為true表示為公平鎖，為fasle為非公平鎖。默認(rèn)情況下，如果使用無參構(gòu)造器，則是非公平鎖。

另外在ReentrantLock類中定義了很多方法，比如：

isFair()        //判斷鎖是否是公平鎖
isLocked()    //判斷鎖是否被任何線程獲取了
isHeldByCurrentThread()   //判斷鎖是否被當(dāng)前線程獲取了 
hasQueuedThreads()   //判斷是否有線程在等待該鎖

在ReentrantReadWriteLock中也有類似的方法，同樣也可以設(shè)置為公平鎖和非公平鎖。

不過要記住，ReentrantReadWriteLock并未實(shí)現(xiàn)Lock接口，它實(shí)現(xiàn)的是ReadWriteLock接口。

4.讀寫鎖

讀寫鎖將對(duì)一個(gè)資源（比如文件）的訪問分成了2個(gè)鎖，一個(gè)讀鎖和一個(gè)寫鎖。

正因?yàn)橛辛俗x寫鎖，才使得多個(gè)線程之間的讀操作不會(huì)發(fā)生沖突。

ReadWriteLock就是讀寫鎖，它是一個(gè)接口，ReentrantReadWriteLock實(shí)現(xiàn)了這個(gè)接口。

可以通過readLock()獲取讀鎖，通過writeLock()獲取寫鎖。

樂觀鎖是假定讀取的數(shù)據(jù)，在寫之前不會(huì)被更新。適用于數(shù)據(jù)更新不頻繁的場(chǎng)景。

相反，當(dāng)數(shù)據(jù)更新頻繁的時(shí)候，樂觀鎖的效率很低，因?yàn)榛旧厦看螌懙臅r(shí)候都要重復(fù)讀寫兩次以上。

對(duì)于數(shù)據(jù)更新頻繁的場(chǎng)合，悲觀鎖效率更高 ；

對(duì)于數(shù)據(jù)更新不頻繁的場(chǎng)合，樂觀鎖效率更高；

一般來說如果并發(fā)量很高的話，建議使用悲觀鎖，否則的話就使用樂觀鎖。

如果并發(fā)量很高時(shí)使用樂觀鎖的話，會(huì)導(dǎo)致很多的并發(fā)事務(wù)回滾、操作失敗。

線程工作內(nèi)存是cpu寄存器和高速緩存的抽象描述，使用頻率高的數(shù)據(jù)從主存拷貝到高速緩存中，每個(gè)線程在cpu高速緩存中對(duì)拷貝的數(shù)據(jù)進(jìn)行讀取、計(jì)算、賦值，再在合適的時(shí)候同步更新到主存的該數(shù)據(jù)，如i=1，i+1=2，若2在更新到主存前，其他線程是不知道該值被改變了，其他線程高速緩存中該值依然為1。

解決方法：需要各線程間可見的變量前加上volatile修飾，在一個(gè)線程的高速緩存中改變?cè)撝禃r(shí)，其他線程會(huì)獲得該值的更新值。

垃圾收集器：

串行：Serial、Parallel、CMS

CMS:每個(gè)垃圾收集周期只有兩次短的停頓，開始時(shí)有一個(gè)短的停頓，稱為初始標(biāo)記；標(biāo)記從外部直接可達(dá)的老年代對(duì)象；然后在并發(fā)標(biāo)記階段，標(biāo)記所有從這些對(duì)象可達(dá)的存活對(duì)象；由于在標(biāo)記期間應(yīng)用可能正在運(yùn)行并更新引用，所以到并發(fā)標(biāo)記階段結(jié)束時(shí)，未必所有存活的對(duì)象都能確保被標(biāo)記；所以必須再次停頓，稱為重新標(biāo)記；最后一個(gè)階段是并發(fā)清除。

dbcp沒有自動(dòng)地去回收空閑連接的功能 c3p0有自動(dòng)回收空閑連接功能 。

兩者主要是對(duì)數(shù)據(jù)連接的處理方式不同！c3p0提供最大空閑時(shí)間，dbcp提供最大連接數(shù)。

前者當(dāng)連接超過最大空閑連接時(shí)間時(shí)，當(dāng)前連接就會(huì)被斷掉。dbcp當(dāng)連接數(shù)超過最大連接數(shù)時(shí)，所有連接都會(huì)被斷開。

dbcp和c3p0都是單線程的，在高并發(fā)的環(huán)境下性能會(huì)非常低下；tomcat jdbc pool 近乎兼容 dbcp ，性能更高，異步方式獲取連接。