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