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

      執行給定的 SQL 語句，該語句可能返回多個結果。

executeQuery(String sql)

      執行給定的 SQL 語句，該語句返回單個 ResultSet 對象

executeUpdate(String sql)

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

頭2種一般在查詢中使用

最后一個在插入、更新、刪除時使用

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

3、executeQuery、executeUpdate或execute方法區別？
在用純JSP做一個頁面報警功能的時候習慣性的用executeQuery來執行SQL語句，結果執行update時就遇到問題，語句能執行，但返回結果出現問題，另外還忽略了executeUpdate的返回值不是結果集ResultSet,而是數值！特收藏如下一篇文章（感謝網友們對各種信息的貢獻）：

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

Statement 接口提供了三種執行 SQL 語句的方法：executeQuery、executeUpdate 和 execute。使用哪一個方法由 SQL 語句所產生的內容決定。

方法executeQuery
用于產生單個結果集的語句，例如 SELECT 語句。 被使用最多的執行 SQL 語句的方法是 executeQuery。這個方法被用來執行 SELECT 語句，它幾乎是使用最多的 SQL 語句。

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

使用executeUpdate方法是因為在 createTableCoffees 中的 SQL 語句是 DDL （數據定義語言）語句。創建表，改變表，刪除表都是 DDL 語句的例子，要用 executeUpdate 方法來執行。你也可以從它的名字里看出，方法 executeUpdate 也被用于執行更新表 SQL 語句。實際上，相對于創建表來說，executeUpdate 用于更新表的時間更多，因為表只需要創建一次，但經常被更新。

方法execute：
用于執行返回多個結果集、多個更新計數或二者組合的語句。因為多數程序員不會需要該高級功能

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

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

如果已經調用方法 getResultSet 并處理了它返回的 ResultSet 對象，則有必要調用方法 getMoreResults 以確定是否有其它結果集或更新計數。如果 getMoreResults 返回 true，則需要再次調用 getResultSet 來檢索下一個結果集。如上所述，如果 getResultSet 返回 null，則需要調用 getUpdateCount 來檢查 null 是表示結果為更新計數還是表示沒有其它結果。

當 getMoreResults 返回 false 時，它表示該 SQL 語句返回一個更新計數或沒有其它結果。因此需要調用方法 getUpdateCount 來檢查它是哪一種情況。在這種情況下，當下列條件為真時表示沒有其它結果：

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

下面的代碼演示了一種方法用來確認已訪問調用方法 execute 所產生的全部結果集和更新計數：

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

　　在傳統的Java應用中，Bean的生命周期非常簡單。Java的關鍵詞new用來實例化Bean（或許他是非序列化的）。這樣就夠用了。相反，Bean 的生命周期在spring容器中更加細致。理解Spring Bean的生命周期非常重要，因為你或許要利用Spring提供的機會來訂制Bean的創建過程。

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

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

3.如果Bean實現了BeanNameAware接口，工廠調用Bean的setBeanName()方法傳遞Bean的ID。

4.如果Bean實現了BeanFactoryAware接口，工廠調用setBeanFactory()方法傳入工廠自身。

5.如果BeanPostProcessor和Bean關聯，那么它們的postProcessBeforeInitialzation()方法將被調用。

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

7.最后，如果有BeanPsotProcessor和Bean關聯，那么它們的postProcessAfterInitialization()方法將被調用。

　　到這個時候，Bean已經可以被應用系統使用了，并且將被保留在Bean Factory中知道它不再需要。有兩種方法可以把它從Bean Factory中刪除掉。

1.如果Bean實現了DisposableBean接口，destory()方法被調用。

2.如果指定了訂制的銷毀方法，就調用這個方法。

　　Bean在Spring應用上下文的生命周期與在Bean工廠中的生命周期只有一點不同，唯一不同的是，如果Bean實現了ApplicationContextAwre接口，setApplicationContext()方法被調用。

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

單例的特點：

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

靜態變量定義某類的實例引用特點：
1、該類的實例引用的靜態變量可定義在任何文檔類當中。
2、獲取該類的實例引用的靜態變量，可以通過定義該靜態變量的類名通過點語法進行訪問該引用。
3、任何位置可以對該靜態變量進行重新賦值。

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

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

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

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

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

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

HashMap是支持null鍵和null值的，而HashTable在遇到null時，會拋出NullPointerException異常。

這并不是因為HashTable有什么特殊的實現層面的原因導致不能支持null鍵和null值，這僅僅是因為HashMap在實現時對null做了特殊處理，將null的hashCode值定為了0，從而將其存放在哈希表的第0個bucket中。

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

2：<%@ include file="top.jsp"%>靜態讀取：則是將top.jsp的整個頁面不加解析（無論是腳本還是指令）統統讀入到引用頁面中，然后和引用頁面一起進行解析（即開始執行腳本和指令）。

3：區別：其實上邊的兩條就是區別，但是需要注意的是用<%@ include file=""%>的時候被引用頁面中不能再出現其他網頁標簽和page指令了，否則會沖突的

（jsp:include page=""）

父頁面和包含進來的頁面多帶帶編譯，多帶帶翻譯成servlet后，在前臺拼成一個HTML頁面。

（%@include file=""%）

父頁面和包含進來的頁面，代碼合并后，才一起翻譯成servlet，反饋到前臺，形成一個HTML頁面。

由此我們知道：jsp頁面是把include指令元素（<%@ include file=""%>）所指定的頁面的實際內容（也就是代碼段）加入到引入它的jsp頁面中,合成一個文件后被jsp容器將它轉化成servlet。可以看到這時會產生一個臨時class文件和一個servlet源文件。而動作元素（）是在請求處理階段引入的，會被JSP容器生成兩個臨時class文件和兩個servlet原文件。而引入的只是servlet的輸出結果，即JspWriter對象的輸出結果，而不是jsp的源代碼。

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

所有的JSP都會在客戶端發出請求后被容器轉譯成servlet的源代碼（java），然后再將源碼（java）編譯成servlet的類（class），放入到內存里面。

1.可重入鎖

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

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

基于線程的分配，而不是基于方法調用的分配。

舉個簡單的例子，當一個線程執行到某個Synchronized方法時，比如說method1，而在method1中會調用另外一個Synchronized方法method2，此時線程不必重新去申請鎖，而是可以直接執行方法method2。

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

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

假如某一時刻，線程A執行到了method1，此時線程A獲取了這個對象的鎖，而由于method2也是Synchronized方法，假如Synchronized不具備可重入性，此時線程A需要重新申請鎖。

但是這就會造成一個問題，因為線程A已經持有了該對象的鎖，而又在申請獲取該對象的鎖，這樣就會線程A一直等待永遠不會獲取到的鎖。

而由于Synchronized和Lock都具備可重入性，所以不會發生上述現象。

2.可中斷鎖

可中斷鎖：顧名思義，就是可以響應中斷的鎖。

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

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

在前面演示LockInterruptibly()的用法時已經體現了Lock的可中斷性。

3.公平鎖

公平鎖即盡量以請求鎖的順序來獲取鎖。比如同是有多個線程在等待一個鎖，當這個鎖被釋放時，等待時間最久的線程（最先請求的線程）會獲得該所，這種就是公平鎖。

非公平鎖即無法保證鎖的獲取是按照請求鎖的順序進行的。這樣就可能導致某個或者一些線程永遠獲取不到鎖。

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

而對于ReentrantLock和ReentrantReadWriteLock，它默認情況下是非公平鎖，但是可以設置為公平鎖。這一點由構造函數可知：

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


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

在ReentrantLock中定義了2個靜態內部類，一個是NotFairSync，一個是FairSync，分別用來實現非公平鎖和公平鎖。

我們可以在創建ReentrantLock對象時，通過知道布爾參數來決定使用非公平鎖還是公平鎖。

如果參數為true表示為公平鎖，為fasle為非公平鎖。默認情況下，如果使用無參構造器，則是非公平鎖。

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

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

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

不過要記住，ReentrantReadWriteLock并未實現Lock接口，它實現的是ReadWriteLock接口。

4.讀寫鎖

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

正因為有了讀寫鎖，才使得多個線程之間的讀操作不會發生沖突。

ReadWriteLock就是讀寫鎖，它是一個接口，ReentrantReadWriteLock實現了這個接口。

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

樂觀鎖是假定讀取的數據，在寫之前不會被更新。適用于數據更新不頻繁的場景。

相反，當數據更新頻繁的時候，樂觀鎖的效率很低，因為基本上每次寫的時候都要重復讀寫兩次以上。

對于數據更新頻繁的場合，悲觀鎖效率更高 ；

對于數據更新不頻繁的場合，樂觀鎖效率更高；

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

如果并發量很高時使用樂觀鎖的話，會導致很多的并發事務回滾、操作失敗。

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

解決方法：需要各線程間可見的變量前加上volatile修飾，在一個線程的高速緩存中改變該值時，其他線程會獲得該值的更新值。

垃圾收集器：

串行：Serial、Parallel、CMS

CMS:每個垃圾收集周期只有兩次短的停頓，開始時有一個短的停頓，稱為初始標記；標記從外部直接可達的老年代對象；然后在并發標記階段，標記所有從這些對象可達的存活對象；由于在標記期間應用可能正在運行并更新引用，所以到并發標記階段結束時，未必所有存活的對象都能確保被標記；所以必須再次停頓，稱為重新標記；最后一個階段是并發清除。

dbcp沒有自動地去回收空閑連接的功能 c3p0有自動回收空閑連接功能 。

兩者主要是對數據連接的處理方式不同！c3p0提供最大空閑時間，dbcp提供最大連接數。

前者當連接超過最大空閑連接時間時，當前連接就會被斷掉。dbcp當連接數超過最大連接數時，所有連接都會被斷開。

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