public static void main(String[] args) {
String sql = "SELECT * FROM \n" +
" `testdb`.`foo` LIMIT 0, 100";
String s = "SELECT * FROM `testdb`.`foo` LIMIT 0, 100";
String sql2 = Pattern.compile(" {2,}").matcher(s).replaceAll(" ");
String sql3 = s.replaceAll(" {2,}"," ");
String sql4 = sql.replace('\r', ' ').replace('\n', ' ').replaceAll(" {2,}"," ");;
String sql5 = sql.replace('\r', ' ').replace('\n', ' ').replaceAll(" {2,}?"," ");;
String sql6 = sql.replace('\r', ' ').replace('\n', ' ').replaceAll(" {2,}+"," ");;
System.out.println(sql2);
System.out.println(sql3);
System.out.println(sql4);
System.out.println(sql5);
System.out.println(sql6);
}

SELECT * FROM `testdb`.`foo` LIMIT 0, 100
SELECT * FROM `testdb`.`foo` LIMIT 0, 100
SELECT * FROM `testdb`.`foo` LIMIT 0, 100
SELECT * FROM `testdb`.`foo` LIMIT 0, 100
SELECT * FROM `testdb`.`foo` LIMIT 0, 100
[code]
Process finished with exit code 0
結(jié)果可以看出，有一個是沒有去掉多余空格的。

可見java中的正則式，同樣含義的還有多重寫法，呵呵！其實主要是不同數(shù)量詞匹配模式在作怪：

原版API文檔中寫道：

Greedy 數(shù)量詞

X? X，一次或一次也沒有
X* X，零次或多次
X+ X，一次或多次
X{n} X，恰好 n 次
X{n,} X，至少 n 次
X{n,m} X，至少 n 次，但是不超過 m 次

Reluctant 數(shù)量詞

X?? X，一次或一次也沒有
X*? X，零次或多次
X+? X，一次或多次
X{n}? X，恰好 n 次
X{n,}? X，至少 n 次
X{n,m}? X，至少 n 次，但是不超過 m 次

Possessive 數(shù)量詞

X?+ X，一次或一次也沒有
X*+ X，零次或多次
X++ X，一次或多次
X{n}+ X，恰好 n 次
X{n,}+ X，至少 n 次
X{n,m}+ X，至少 n 次，但是不超過 m 次


但是，沒有對三種方式進(jìn)行更詳細(xì)的說明，其實三種模式的區(qū)別如下：

Greedy ：嘗試找到最長的匹配。
Reluctant ：嘗試找到最短的匹配。
Possessive ：也嘗試找到最長的匹配。

盡管greedy和possessive迫使一個matcher在進(jìn)行第一次匹配之前讀取整個的text，greedy常常導(dǎo)致為了找到一個match進(jìn)行多次嘗試，然而possessive讓一個matcher僅嘗試一個match一次。

下面是一個我工具中的方法：
[code]
/**
* 判斷一條SQL語句是否已經(jīng)是分頁的SQL
*
* @param sql 源SQL
* @return 是已經(jīng)分頁的SQL時返回ture，否則返回False；
*/
public boolean isAlreadySegmentSQL(String sql) {
return sql.replace('\r', ' ').replace('\n', ' ').replaceAll(" {2,}", " ").matches("(?i).+LIMIT [\\d+ *|\\d *, *\\d+].+");
}

// regList.put("(?i)bit\\([2-9]\\)\\z", "byte[]");
// regList.put("(?i)bit\\(\\d{2,}\\)\\z", "byte[]");
regList.put("(?i)bit\\((\\d{2,}|[2-9])\\)\\z", "byte[]");