Linux下如何使用Vi編輯器 收藏

要對正文內容進行修改，首先必須把光標移動到指定位置。移動光標的最簡單的方式是按鍵盤的上、下、左、

右箭頭鍵。除了這種最原始的方法之外，用戶還可以利用 vi 提供的眾多字符組合鍵，在正文中移動光標，迅

速到達指定的行或列，實現定位。例如：

k、j、h、l      功能分別等同于上、下、左、右箭頭鍵

Ctrl+b          在文件中向上移動一頁（相當于 PageUp 鍵）

Ctrl+f          在文件中向下移動一頁（相當于 PageDown 鍵）

H               將光標移到屏幕的最上行（Highest）

nH              將光標移到屏幕的第 n 行

2H              將光標移到屏幕的第 2 行

M               將光標移到屏幕的中間（Middle）

L               將光標移到屏幕的最下行（Lowest）

nL              將光標移到屏幕的倒數第 n 行

3L              將光標移到屏幕的倒數第 3 行

w               在指定行內右移光標，到下一個字的開頭

e               在指定行內右移光標，到一個字的末尾

b               在指定行內左移光標，到前一個字的開頭

0               數字0，左移光標，到本行的開頭

$               右移光標，到本行的末尾

^               移動光標，到本行的第一個非空字符

將光標定位于文件內指定位置后，可以用其他字符來替換光標所指向的字符，或從當前光標位置刪除一個或多

個字符。例如：

rc              用 c 替換光標所指向的當前字符

nrc             用 c 替換光標所指向的前 n 個字符

5rc             用 c 替換光標所指向的前 5 個字符

x               刪除光標所指向的當前字符

nx              刪除光標所指向的前 n 個字符

3x              刪除光標所指向的前 3 個字符

dw              刪除光標右側的字

ndw             刪除光標右側的 n 個字

3dw             刪除光標右側的 3 個字

db              刪除光標左側的字

ndb             刪除光標左側的 n 個字

5db             刪除光標左側的 5 個字

dd              刪除光標所在行，并去除空隙

ndd             刪除 n 行內容，并去除空隙

3dd             刪除 3 行內容，并去除空隙

從正文中刪除的內容（如字符、字或行）并沒有真正丟失，而是被剪切并復制到了一個內存緩沖區中。用戶可

將其粘貼到正文中的指定位置。完成這一操作的命令是：

p               小寫字母 p，將緩沖區的內容粘貼到光標的后面

P               大寫字母 P，將緩沖區的內容粘貼到光標的前面

如果緩沖區的內容是字符或字，直接粘貼在光標的前面或后面；如果緩沖區的內容為整行正文，則粘貼在當前

光標所在行的上一行或下一行。

注意上述兩個命令中字母的大小寫。vi 編輯器經常以一對大、小寫字母（如 p 和 P）來提供一對相似的功能

。通常，小寫命令在光標的后面進行操作，大寫命令在光標的前面進行操作。

有時需要復制一段正文到新位置，同時保留原有位置的內容。這種情況下，首先應當把指定內容復制（而不是

剪切）到內存緩沖區。完成這一操作的命令是：

yy              復制當前行到內存緩沖區

nyy             復制 n 行內容到內存緩沖區

5yy             復制 5 行內容到內存緩沖區

和許多先進的編輯器一樣，vi 提供了強大的字符串搜索功能。要查找文件中指定字或短語出現的位置，可以

用 vi 直接進行搜索，而不必以手工方式進行。搜索方法是：鍵入字符 / ，后面跟以要搜索的字符串，然后

按回車鍵。編輯程序執行正向搜索（即朝文件末尾方向），并在找到指定字符串后，將光標停到該字符串的

開頭；鍵入 n 命令可以繼續執行搜索，找出這一字符串下次出現的位置。用字符 ? 取代 / ，可以實現反向

搜索（朝文件開頭方向）。例如：

/str1           正向搜索字符串 str1

n               繼續搜索，找出 str1 字符串下次出現的位置

?str2           反向搜索字符串 str2

無論搜索方向如何，當到達文件末尾或開頭時，搜索工作會循環到文件的另一端并繼續執行。

在編輯文檔的過程中，為消除某個錯誤的編輯命令造成的后果，可以用撤消命令。另外，如果用戶希望在新

的光標位置重復前面執行過的編輯命令，可用重復命令。

u               撤消前一條命令的結果

.               重復最后一條修改正文的命令

在編輯模式下正確定位光標之后，可用以下命令切換到插入模式：

i               在光標左側輸入正文

a               在光標右側輸入正文

o               在光標所在行的下一行增添新行

O               在光標所在行的上一行增添新行

I               在光標所在行的開頭輸入正文

A               在光標所在行的末尾輸入正文

上面介紹了幾種切換到插入模式的簡單方法。另外還有一些命令，它們允許在進入插入模式之前首先刪去一段

正文，從而實現正文的替換。這些命令包括：

s               用輸入的正文替換光標所指向的字符

ns              用輸入的正文替換光標右側 n 個字符

cw              用輸入的正文替換光標右側的字

ncw             用輸入的正文替換光標右側的 n 個字

cb              用輸入的正文替換光標左側的字

ncb             用輸入的正文替換光標左側的 n 個字

cd              用輸入的正文替換光標的所在行

ncd             用輸入的正文替換光標下面的 n 行

c$              用輸入的正文替換從光標開始到本行末尾的所有字符

c0              用輸入的正文替換從本行開頭到光標的所有字符

退出插入模式的方法是，按 ESC 鍵或組合鍵Ctrl+[ 。

在編輯模式下可以用 ZZ 命令退出 vi 編輯程序，該命令保存對正文所作的修改，覆蓋原始文件。如果只需要

退出編輯程序，而不打算保存編輯的內容，可用下面的命令：

: q             在未作修改的情況下退出

: q!            放棄所有修改，退出編輯程序

編輯中的每一行正文都有自己的行號，用下列命令可以移動光標到指定行：

: n             將光標移到第 n 行

命令模式下，可以規定命令操作的行號范圍。數值用來指定絕對行號；字符“.”表示光標所在行的行號；字符

符“___FCKpd___8rdquo;表示正文最后一行的行號；簡單的表達式，例如“.+5”表示當前行往下的第 5 行。例如：

:345                將光標移到第 345 行

:345w file      將第 345 行寫入 file 文件

:3,5w file      將第 3 行至第 5 行寫入 file 文件

:1,.w file      將第 1 行至當前行寫入 file 文件

:.,$w file      將當前行至最后一行寫入 file 文件

:.,.+5w file        從當前行開始將 6 行內容寫入 file 文件

:1,$w file      將所有內容寫入 file 文件，相當于 :w file 命令

在命令模式下，允許從文件中讀取正文，或將正文寫入文件。例如：

:w              將編輯的內容寫入原始文件，用來保存編輯的中間結果

:wq             將編輯的內容寫入原始文件并退出編輯程序（相當于 ZZ 命令）

:w file         將編輯的內容寫入 file 文件，保持原有文件的內容不變

:a,bw file      將第 a 行至第 b 行的內容寫入 file 文件

:r file         讀取 file 文件的內容，插入當前光標所在行的后面

:e file         編輯新文件 file 代替原有內容

:f file         將當前文件重命名為 file

:f              打印當前文件名稱和狀態，如文件的行數、光標所在的行號等

給出一個字符串，可以通過搜索該字符串到達指定行。如果希望進行正向搜索，將待搜索的字符串置于兩個“

/”之間；如果希望反向搜索，則將字符串放在兩個“?”之間。例如：

:/str/                      正向搜索，將光標移到下一個包含字符串 str 的行

:?str?                      反向搜索，將光標移到上一個包含字符串 str 的行

:/str/w file                正向搜索，并將第一個包含字符串 str 的行寫入 file 文件

:/str1/,/str2/w file        正向搜索，并將包含字符串 str1 的行至包含字符串 str2 的行寫

入 file 文件

利用 :s 命令可以實現字符串的替換。具體的用法包括：

:s/str1/str2/       用字符串 str2 替換行中首次出現的字符串 str1

:s/str1/str2/g      用字符串 str2 替換行中所有出現的字符串 str1

:.,$ s/str1/str2/g  用字符串 str2 替換正文當前行到末尾所有出現的字符串 str1

:1,$ s/str1/str2/g  用字符串 str2 替換正文中所有出現的字符串 str1

:g/str1/s//str2/g   功能同上

從上述替換命令可以看到：g 放在命令末尾，表示對搜索字符串的每次出現進行替換；不加 g，表示只對搜索

字符串的首次出現進行替換；g 放在命令開頭，表示對正文中所有包含搜索字符串的行進行替換操作。

在命令模式下，同樣可以刪除正文中的內容。例如：

:d                  刪除光標所在行

:3d                 刪除 3 行

:.,$d               刪除當前行至正文的末尾

:/str1/,/str2/d     刪除從字符串 str1 到 str2 的所有行

vi 在編輯某個文件時，會另外生成一個臨時文件，這個文件的名稱通常以 . 開頭，并以 .swp 結尾。vi 在

正常退出時，該文件被刪除，若意外退出，而沒有保存文件的最新修改內容，則可以使用恢復命令：

:recover           恢復文件

也可以在啟動 vi 時利用 -r 選項。

為控制不同的編輯功能，vi 提供了很多內部選項。利用 :set 命令可以設置選項。基本語法為：

:set option         設置選項 option

常見的功能選項包括：

autoindent          設置該選項，則正文自動縮進

ignorecase          設置該選項，則忽略規則表達式中大小寫字母的區別

number              設置該選項，則顯示正文行號

ruler               設置該選項，則在屏幕底部顯示光標所在行、列的位置

tabstop             設置按 Tab 鍵跳過的空格數。例如 :set tabstop=n，n 默認值為 8

mk                  將選項保存在當前目錄的 .exrc 文件中

在編輯正文時，利用 vi 命令模式下提供的 shell 切換命令，無須退出 vi 即可執行 Linux 命令，十分

方便。語法格式為：

:! command          執行完 shell 命令 command 后回到 vi

另外，在編輯模式下，鍵入 K ，可命令 vi 查找光標所在單詞的手冊頁，相當于運行 man命令。

無意間發現這個排行榜，有點意思... (修改了一些模式名稱)

[轉載自竹筍炒肉 Hedong’s blog November 24, 2009]

Java設計模式使用率爬行榜

轉自2004年6期《CSDN開發高手》

在Java編程中，Singleton 模式可算得上是應用最廣泛的一種設計模式了。它大量得被用于各種流行的框架中，包括最基本的 JDK 代碼中。從代碼來說， Singleton 的實現很簡單，但是真正用好并不容易，幾年的開發設計工作中經常都遇到由于沒有弄清實例的單態或非單態性，以及不恰當得使用單態導致的問題。

基本概念：

從分類來說，Singleton 屬于創建型(Construction)模式，最基本的目標是要保證在一個JVM中，一個 Class 最多只有一個實例存在。而要達成這個目標背后的驅動力是： 減少不必要的資源和時間的開銷。

• 資源：在內存中每個對象實例都要占據一定空間，當程序不需要為每個線程在該對象中保存不同的狀態時，就可以用Singleton 模式，永遠只用一個對象實例為所有線程服務。
• 時間：在JVM中每次構造一個對象實例都是有一定時間消耗的，用Singleton 模式可以幫助程序提高性能，只有第一次初始化實例時需要時間消耗，以后每次引用的時間消耗都幾乎為零。

Singleton 最根本的價值就在于“節省資源”！盡管這種設計被廣泛使用，但是在單線程或低并發環境中，它在性能和資源節省上帶來的價值并不大，越是高并發的多線程環境，Singleton 所能帶來的價值越明顯！(當然前提是你能夠正確使用它)

反駁：

1. 現在有些文章（其實是老外N年前就討論過的問題）在評論到底還需不需要用 Singleton 模式，在討論 Singleton 是不是邪惡的：） 其實辯證地看，世間被就沒有什么東西是絕對好或不好，關鍵看你怎么利用它。如果程序員對 Singleton 模式理解不深，不恰當使用，確實會導致嚴重問題，但這不代表這個模式是不該存在的。就如同C語言的指針，很多人用錯，但是不能說指針就是一個錯誤的設計。是天使還是魔鬼都取決與利用它的人。

2. 現在有些人說 Singleton 已經過時了，不需要了，仿佛 IOC 模式已經把一切關于 bean 創建的問題都解決了。我不這樣認為。也許現在程序員或架構師已經不需要自己實現 Singleton 了，但這只是因為 Singleton 的實現已經被一些成熟的框架包辦，程序員不需要自己去關心了，并不是說 Singleton 不存在。我們仍然需要控制對象實例的數目來達到節省資源，減少開銷的目的！如果程序員對 Singleton 沒有足夠的理解，也很難正確有效得使用幫我們包辦一切的框架，如 Spring。

模式實現：

經過人們對 Singleton 多年的使用，通常有兩種公認的線程安全的實現（并非全部）：

1. Lazy initialization:

提供一個synchronized getInstance() 方法來檢查對象實例是否已創建。如果是，直接返回引用；如果不是，創建實例并返回。并將缺省的構造器方法定義為 private：

class Singleton {

    private static Singleton _instance;

    private int _state;

    private Singleton() {

        _state = 0;

    }

    public static synchronized Singleton getInstance() {

        if (_instance == null)

            _instance = new Singleton();

    return _instance;

    }

}

2. Aggressive initialization:

拋棄 synchronized，而使用靜態屬性，在類載入時立即初始化，同樣需要把缺省的構造器方法定義為 private:

class Singleton {

    private int _state;

    private static Singleton _instance = new Singleton();

    private Singleton() {

        _state = 0;

    }

    public static Singleton getInstance() {

        return _instance;

    }

}

問題分析：

1. 上面的第一種實現雖然可行，但是有一個缺點就是多余的 synchronized 消耗：事實上 Singleton 的實例化只有在第一次實際進行 new Singleton() 的時候需要 synchronized，從那以后每次調用 getInstance() 方法只需要簡單返回 _instance 引用就可以了，而此時 synchronized 需要的消耗就成了浪費！

2. 我曾經在不止一次的項目中看到過如下的代碼來實現 Singleton，這是為了解決上面的 synchronized 浪費：

class Singleton {

    private static Singleton _instance;

    private int _state;

    private Singleton() {

        _state = 0;

    }

    public static Singleton getInstance() {

        if (_instance == null) {

            synchronized (Singleton.class) {

                _instance = new Singleton();

            }

        }

        return _instance;

    }

}

這個實現在單線程環境下不會出問題，但是放到并發的環境中是有問題的，線程并不真正安全。多個線程有可能同時進入 if(_instance == null) 內部，而導致程序實際創建出多個對象實例！

3. 還有一種 Double-checked locking 的實現，試圖解決上面兩個問題：

class Singleton {

    private static Singleton _instance;

    private int _state;

    private Singleton() {

        _state = 0;

    }

    public static Singleton getInstance() {

        if (_instance == null) {

            synchronized (Singleton.class) {

                if (_instance == null)

                    _instance = new Singleton();

            }

        }

        return _instance;

    }

}

可以看到這個實現煞費苦心，在 synchronized 內部再判斷一次 if(_instance == null)。于是在單線程和低并發環境下，這個實現很難出問題了，但是到了足夠高并發的環境中，線程再次變得不安全。這個問題是由 Java 平臺的內存模式引起的，也與不同的 JIT 編譯器的編譯方式有關，稱之為“out-of-order writes”：一個實例 _instance 有可能在 new Singleton() 沒有完全初始化的時候就已經不再是 null，于是并發線程可能得到一個沒有完全初始化的實例，從而引起錯誤。

有很多關于 Double-checked locking 或 out-of-order writes 的分析文章，推薦：

Double-checked locking and the Singleton pattern

4. 看過一些關于 Singleton 的文章，提到 Singleton 的另一個用途，可以用來保持全局狀態，如網站計數器。確實 Singleton 可以幫助我們達到這個目的，但是仔細想想，其實任意一個類靜態變量都可以達到這個目的，Singleton不是必需。而且考慮 Singleton 模式使用中帶有的陷阱，它并不是一個好的辦法來達到保持全局狀態的目的。

5. Singleton 模式只能保證在單 JVM 中只創建一個對象實例！相同的代碼一旦部署到集群或分布式環境中就可能出錯，Singleton 完全失效了！在分布式環境中，StatelessSession bean 是一個好的選擇。

6. 綜上所述，Singleton 模式有它特定的適用場合，達到特定的目的（節省資源！）。除非必要，盡量不要用 Singleton！

記錄下我在安裝和配置Ubuntu9.10中遇到和解決的問題，按順序：

首先是安裝：

Ubuntu的安裝其實很簡單，但因為我光驅的問題（唉，懷疑我的DVD-RAM光驅老化了），折騰了好幾天… 最終放棄想刻錄一張啟動DVD盤的嘗試，另辟蹊徑，卻發現一個簡單得多的辦法，U盤啟動：）

先說明，從官網下載了 ubuntu-9.10-desktop-i386.iso 鏡像后，其實隨便用一個光盤鏡像工具就可以加載并安裝 Ubuntu 了，但是這種方式不能將 Ubuntu 安裝到一個獨立的Linux分區，它和 Windows 使用相同的分區，就像其它應用程序一樣，系統性能會受到很大的影響。

這是我的方法（當然是網上找到的方法 http://ubuntuforums.org/showthread.php?t=427540）：

1. 從官網下載 ubuntu-9.10-desktop-i386.iso 鏡像 http://www.ubuntu.org.cn/;

2. 下載一個 UNetbootin 工具(http://zh.wikipedia.org/wiki/UNetbootin)，該工具用于制作 Live USB 系統，可以制作各種 Linux 系統的安裝盤，而不需要光盤。

    UNetbootin 設置：

     a. Distribution: Ubuntu, Daily Live; (我下載的 UNetbootin 中暫時還沒有專門針對 v9.10 的，所以我選了這個)

     b. Diskimage: ISO, <選擇我下載的iso鏡像>

     c. Type: USB Drive, <U盤的盤符>

    確定之后該工具會把所有安裝Ubuntu需要的文件復制到U盤，并且制作引導程序，之后重啟…

3. 重啟后選擇從U盤啟動，GRUB程序會自動運行，之后的安裝和用光盤啟動是一樣的，不用多講的，非常簡單。

    唯一需要指出的是：安裝過程中會讓你選擇將 Ubuntu 安裝到哪個盤，建議你安裝到一個獨立的分區，而不要和 Windows side by side (如果你要保留 Windows 的話)；另外創建一個和物理內存大小相同的 Linux Swap 分區，這些都是安裝 Linux 的常識了。

配置應用：

1. 無線網連接

    Ubuntu 可以很好地支持大多數網卡，自動檢測到附近的無線網。點擊右上角的無線網圖標，選擇我的網絡并輸入WEP密鑰，OK了，非常簡單！

2. 中文輸入（我裝的是英文系統，如果Ubuntu安裝時就是選擇簡體中文，可能沒有這么麻煩吧）

    首先需要給系統安裝語言包，使得 Linux 支持該語言的文字顯示和輸入。進入"System"- "Administration" - "Language Support" 窗口, 首先就是一大推包下載和安裝，應該是系統基本的語言支持包；

    完成后，在 "Language Support" 窗口中點擊 "Install/Remove Language"，選擇 "Chinese(simplified)" 并選中所有的選項，應用… 于是開始15個語言包的下載和安裝（這回肯定是支持簡體中文的了）；

    上一步完成后中文輸入就已經安裝了，不過需要手動添加到可用的輸入法中：在 "Language Support" 中輸入法選擇 "ibus"（這是一個 Linux 下的輸入法平臺，代替以前老的 SCIM）。再在 "System"- "iBus Setup" 中啟動 ibus 應用，并且選擇 “PinYin”等你需要的中文輸入法添加到列表，設置輸入法切換快捷鍵，完成；

    重啟… 搞定！（之前我嘗試安裝基于SCIM的fcitx和fitx，總是失敗… 放棄） 個人覺得基于 ibus 的輸入法已經很不錯了。

/   根目錄 

│ 

├boot/      啟動文件。所有與系統啟動有關的文件都保存在這里 

│    └grub/   Grub引導器相關的文件 

│ 

├dev/       設備文件 

├proc/      內核與進程鏡像 

│ 

├mnt/      臨時掛載 

├media/   掛載媒體設備 

│ 

├root/      root用戶的$HOME目錄 

├home/          

│    ├user/   普通用戶的$HOME目錄 

│    └.../ 

│ 

├bin/      系統程序 

├sbin/      管理員系統程序 

├lib/      系統程序庫文件 

├etc/      系統程序和大部分應用程序的全局配置文件 

│   ├init.d/   SystemV風格的啟動腳本 

│   ├rcX.d/   啟動腳本的鏈接，定義運行級別 

│   ├network/   網絡配置文件 

│   ├X11/      圖形界面配置文件 

│ 

├usr/       

│   ├bin/      應用程序 

│   ├sbin/   管理員應用程序 

│   ├lib/      應用程序庫文件 

│   ├share/   應用程序資源文件 

│   ├src/      應用程序源代碼 

│   ├local/       

│   │     ├soft/      用戶程序       

│   │     └.../      通常使用單獨文件夾 

│   ├X11R6/   圖形界面系統 

│ 

├var/         動態數據 

│ 

├temp/         臨時文件 

├lost+found/   磁盤修復文件

一些命令：

1. 改變路徑：cd /home/yaoanf

2. 刪除目錄：rm -r /usr/HTTPServer/htdocs/en_US/wwprt/modelReport

3. FTP上傳：ftp D:/workspace/modelReport to /home/yaoanf

4. 移動目錄：mv /home/yaoanf/modelReport /usr/HTTPServer/htdocs/en_US/wwprt

5. 修改權限：chmod -R 755 /usr/HTTPServer/htdocs/en_US/wwprt/modelReport

從09年1月份開始在項目中推行測試驅動開發，在實踐中有一些所得：

1. （TDD的基本原則）如果需要對代碼的邏輯行為做任何修改，必須思考并先創建單元測試用例。

2. TDD的初衷是可以完全取代 Low Level Design。但是在實踐中發現，對于大多數新的TDD程序員，要在完全沒有詳細設計之前寫出有效實用的單元測試用例是非常困難的事情。其實這是個思維習慣問題（我們絕大多數人都習慣了用文字來描述場景和問題，而不習慣用代碼來做同樣的事情，仿佛代碼沒有文字直觀），經過有意識地訓練，我發現用測試代碼來描述問題更具體，更節省時間。那么對于經驗不足的程序員，一個折中的辦法是，可以允許他在寫測試代碼前有一個簡單的詳細設計文檔。但是注意：這個文檔不是一個很正式的可參考的設計文檔，不是我們的 work product ，它僅僅用于幫助經驗不夠的程序員進行思考分析。（在敏捷開發實踐中，我們提倡 Simple Design，設計不應該描述太多的代碼細節）

3. 在設計文檔中（無論是 High Level Design 或 Detail Design），我們需要對預期需要的單元測試用例進行描述，比如羅列出單元測試需要測試哪些場景。這有兩個好處：

a. 強制設計人員在寫設計時就考試考慮如何進行驗證；

b. 確保程序員在 coding 時不會忘記某些必要的測試。

4. 如果有 Code Review 的流程，單元測試用例和運行結果也必須是代碼審查活動的一部分。

5. 單元測試用例必須要被頻繁的執行或重構，團隊需要保證提交到版本控制庫里的所有代碼的測試用例在任何時候都可以成功通過（建議部署持續集成CI的流程來自動化單元測試執行），不是僅僅在開發的時候寫一次就自不維護了。而且一個程序員寫的測試用例要能夠很容易得被其它程序員執行。

6. 盡可能將測試數據和用到它的測試代碼放在同一個類中或同一個目錄下，盡可能將不同單元測試用例的測試數據隔離，避免互相影響（除了一些基礎數據，業務測試數據可以在每個用例測試前創建，測試后清除）；程序員需要保證，單元測試用例的執行不能過于依賴本地數據和環境的配置。

7. TDD的單元測試用例應該從需求，從業務場景的角度來思考和創建，而不是像傳統單元測試那用針對每個類，每個方法來寫測試。記住：真正的TDD是一個業務驅動的設計和開發方法！

More to be added...

用了 Derby 數據庫好一段時間了，雁過留痕。

作為內存數據庫或嵌入式數據庫，Derby 是一個很好的選擇，完全由 Java 實現，在 JDK1.6 中 Derby 已經作為其一部分來發布了，稱之為 JavaDB。

Derby 數據庫通過 derby.properties 文件來配置，這個文件需要放在程序的 classpath 或者 jdk 的 javadb classpath 路徑中。下面是一些配置的例子：

---------------------------- Derby derby.properties information ----------------------------
--### Derby System Home Directory
derby.system.home=D:/workspace/Boulevard/BoulevardDB

Derby 數據庫可以啟動為兩種不同的模式：嵌入式模式 或 服務器模式

1. 嵌入式模式（embedded）：當 Java 應用程序第一次嘗試連接數據庫時啟動數據庫實例，當程序進程結束時數據庫實例也被關閉。當數據庫實例啟動后，僅僅啟動它的進程可以訪問，其它任何外部進程（運行在當前進程的JVM之外的程序）都不能訪問。

    下面的命令用于啟動并連接一個嵌入式數據庫實例：
------------------------------- Derby connection information -------------------------------
-- ### Use ij command to connect embeded database; if not exist, create it.
CONNECT 'jdbc:derby:data;create=true;user=alfred;password=alfred' AS CUBE;
-- ### Use ij command to connect embeded database; if not exist, don't create it, throw out error.
CONNECT 'jdbc:derby:data;user=alfred;password=alfred' AS CUBE;
------------------------------- Derby connection information -------------------------------

2. 服務器模式（network server）：數據庫實例只能由命令行啟動："...\javadb\bin\startNetworkServer.bat"，該實例始終有效，直到通過命令行停止："...\javadb\bin\stopNetworkServer.bat"。任何運行在本地或遠程的JVM進程都可以訪問，不會隨著訪問它的程序的結束而關閉。

    下面的命令用于連接（不能啟動）服務器數據庫實例：
------------------------------- Derby connection information -------------------------------
-- ### Use ij command to connect network server database, reading default repository;
-- ### If not exist, create it.
CONNECT 'jdbc:derby://localhost:1527/data;create=true;user=alfred;password=alfred' AS BOULEVARD;
-- ### Use ij command to connect network server database; reading default repository;
-- ### If not exist, don't create it, throw out error.
CONNECT 'jdbc:derby://localhost:1527/data;user=alfred;password=alfred' AS BOULEVARD;
-- ### Use ij command to connect network server database, reading specific repository;
-- ### If not exist, create it.
CONNECT 'jdbc:derby://localhost:1527/D:/workspace/Boulevard/BoulevardDB/data;create=true;user=alfred;password=alfred' AS BOULEVARD;
-- ### Use ij command to connect network server database, reading specific repository;
-- ### If not exist, don't create it, throw out error.
CONNECT 'jdbc:derby://localhost:1527/D:/workspace/Boulevard/BoulevardDB/data;user=alfred;password=alfred' AS BOULEVARD;
------------------------------- Derby connection information -------------------------------

Hibernate提供了三個級別的緩存策略：Session緩存（基本的事務級緩存），Query Cache（查詢緩存），Seond-Level Cache（二級緩存）

Session緩存（First-Level Cache）：Session是Hibernate用于管理持久化對象的核心機制，它是針對持久性數據的事務級緩存。PersistenceContext中包括：

entityKeys，collectionKeys，

insertion，updates，deletions，

collectionCreations，collectionRemovals，collectionUpdates

由此可見，Session不會把所有的持久化對象實體本身緩存，而只是緩存實體或Collection的Identiy值，和狀態被更新過的實體或Collection（包括插入，更新，刪除）

當Session中緩存的內容過多時會導致OutOfMemory的問題，可以通過兩種方式刪除緩存的內容：

• clear(): 清除所有Session緩存；
• evict(PersistentObject): 將一個特定持久化對象從Session緩存中刪除。 

Query Cache：Hibernate可以對頻繁進行的查詢（相同查詢，相同參數）進行緩存以提高效率。但是查詢緩存不會緩存結果集中實際的數據實體，而是只緩存Identiy值和結果值類型，因此它應該總是和二級緩存一起使用。但由于實際環境中完全相同的頻繁查詢很少，所以默認該緩存是disabled的。可以通過兩種方式使之生效：（個人覺得這個緩存意義不大）

配置屬性：<prop key="hibernate.cache.use_query_cache">true</prop>

代碼：Query.setCacheable(true)

Second-Level Cache:  二級緩存，用于對持久化對象實體或Collection的實際數據進行緩存，用于提供一個集群級別（cluster level），JVM級別，或文件系統級的緩存機制。Hibernate的二級緩存通常都是由第三方的開源項目提供，可以通過配置選擇特定的緩存實現，例如：EHCache，OSCache，JBoss Cable等。

配置屬性：<prop key="hibernate.cache.provider_class">org.hibernate.cache.OSCacheProvider</prop>

二級緩存同樣可以通過兩種方式來管理：

配置屬性：<prop key="hibernate.cache.use_second_level_cache">false</prop>

代碼：Query.setCacheMode(CacheMode.IGNORE) （或者GET，NORMAL，PUT，REFRESH）

• IGNORE: 禁用二級緩存
• NORMAL: 啟用二級緩存，正常讀寫
• GET: 只從二級緩存讀，除非有數據update
• PUT: 只向二級緩存寫
• REFRESH: 強制對寫入二級緩存的內容進行刷新

最后，在程序調試中，我們可能需要查看各種Cache中實際緩存的內容，可以通過配置屬性讓Hibernate收集緩存統計信息。當我們遭遇可能由于緩存導致的問題時，這一方法特別有用。

配置屬性：<prop key="hibernate.generate_statistics">true</prop>

在代碼中獲得統計信息：sessionFactory.getStatistics()

在做自動定價流程的性能測試中，發現一個很棘手的性能問題：一個非常簡單的查詢跑起來非常非常慢，幾乎每一秒鐘只從數據庫返回一條記錄！數據庫是zLinux Server 上的 DB2 8.5，CPU Utilization 只有 35% 而已。

花了大半天時間，最后我以為是數據庫的問題（因為是由別人管理的遠程數據庫），SQL如此簡單應該沒有問題；但是從DBA的反饋是他檢查了數據庫的所有狀態，一切正常:( 我幾乎崩潰…

但今天，最終還是承認SQL確實有問題，而且犯大忌 （對查詢優化的認識有待提高啊…）

-- less 1 record inserted per second, 30000 records insertion need 10 hours
-- to complete (timeout...)
INSERT INTO WWPRT.CABLEPRODUCT_PRICETYPE_JOIN_CN (CABLEPRODUCTID,
PRICETYPE, SLAVE) 
(
     SELECT cableproduct.ID, pricetypes.PRICETYPE, 'N'
     FROM WWPRT.CABLE_PRODUCT_JOIN_CN AS cableproduct,
     (
          SELECT DISTINCT usprice.PRICETYPE FROM WWPRT.PRICE_CN usprice
          JOIN WWPRT.CONF_PRICETYPE pt ON pt.ID = usprice.PRICETYPE
          WHERE usprice.CABLEID = 'USCABF3FVT01'
          AND pt.DOMAIN IN ( SELECT DISTINCT DOMAIN FROM WWPRT.CONF_GAP )
     ) AS pricetypes
     WHERE CABLEID = 'GEOANNF3FVT1'
     AND EXISTS (
         ......
     )
)

其罪魁禍首就是“from”分句中的 subselect 語句，數據庫會對 WWPRT.CABLE_PRODUCT_JOIN_CN 表中的每一條記錄都執行一次上面的 subselect 語句，太可怕了！修改了 SQL 如下，讓上面的 subselect 部分只執行一次作為臨時表：

-- 30000 records insertion only costs 9 seconds to complete!
WITH US_PRICETYPES (PRICETYPE) AS (
    SELECT DISTINCT usprice.PRICETYPE FROM WWPRT.PRICE_CN usprice
    JOIN WWPRT.CONF_PRICETYPE pt ON pt.ID = usprice.PRICETYPE
    LEFT OUTER JOIN WWPRT.CONF_GAP gap ON pt.DOMAIN = gap.DOMAIN
    WHERE usprice.CABLEID = 'USCABF3FVT01'
    AND gap.DOMAIN IS NOT NULL
)
SELECT COUNT(*) FROM NEW TABLE
(
    INSERT INTO WWPRT.CABLEPRODUCT_PRICETYPE_JOIN_CN
    (CABLEPRODUCTID, PRICETYPE, SLAVE)
    (
    SELECT cableproduct.ID, pricetypes.PRICETYPE, 'N'
    FROM WWPRT.CABLE_PRODUCT_JOIN_CN AS cableproduct,
    US_PRICETYPES AS pricetypes
    WHERE CABLEID = 'GEOANNF3FVT1'
    AND EXISTS (
        ......
    )
))

性能的改進太可怕了，需要10個小時跑完的查詢10秒就結束了！盡管我用的是DB2，但我想對其它數據庫應該也有這樣的問題，沒有驗證過…

Followed:
--------------------------------------------------------------------------------------
謝謝Daniel的建議：

如果程序不關心究竟有多少條記錄被插入了，可以用另一個 Fetch，而不是 Count(*)，這樣性能會更好：

SELECT CABLEPRODUCTID FROM NEW TABLE
(INSERT INTO WWPRT.CABLEPRODUCT_PRICETYPE_JOIN_CN (CABLEPRODUCTID,
PRICETYPE, SLAVE)
(
     SELECT cableproduct.ID, pricetypes.PRICETYPE, 'N'
     FROM WWPRT.CABLE_PRODUCT_JOIN_CN AS cableproduct,
     US_PRICETYPES AS pricetypes
     WHERE CABLEID = 'GEOANNF3FVT1'
     AND EXISTS (
         ......
     )
)) FETCH FIRST 1 ROWS ONLY