Ctrl-N              Class... (find by name)
Ctrl-Shift-N        File... (find by name)
Ctrl-Shift-Alt-N    Symbol... (find by name)
Ctrl-G              Line... (goto line)
Ctrl-H              Type hierarchy (hierarchy)
Ctrl-Shift-H        Method hierarchy (hierarchy)
Ctrl-Alt-H          Call hierarchy (hierarchy)
Ctrl-Q              Quick documentation
Ctrl-Alt-I          Auto-indent lines (indent)
Ctrl-Alt-L          Reformat code (line up)
Ctrl-Alt-O          Optimize imports (optimize)
Ctrl-/              Comment with line comment (//)
Ctrl-Shift-/        Comment with block comment (/*...*/)
Ctrl-W              Select word or block (word)
Ctrl-D              Copy line (duplicate line, yyp)
Ctrl-X              Cut line (dd)
Ctrl-U              Uppercase/lowercase (upper)
Ctrl-J              Insert live template
Ctrl-Alt-J          Surround with live template
Ctrl-Alt-T          Surround with (template)
Ctrl-Shift-J        Join lines (join)
Ctrl-E              Recent files (editions)
Ctrl-Shift-E        Recently changed files (editions)
Alt-Shift-C         Recent changes (changes)
Ctrl-B              Delcaration
Ctrl-Shift-B        Type declaration
Ctrl-Alt-B          Implementation(s)
Ctrl-P              Parameter info (parameter)
Ctrl-Space          Basic completion
Ctrl-Shift-Space    Smart completion
Ctrl-Alt-Space      Completion lookup
Alt-Enter           Auto-complete
Alt-Insert          Generate...
Ctrl-Shift-Up/Down  Move statement up/down
Alt-Shift-Up/Down   Move line up/down
Ctrl-Up/Down        Scroll up/down
Alt-Up/Down         Previous/next method
F2                  Next highlighted error
Shift-F2            Previous highlighted error
Ctrl-F              Find
Ctrl-R              Replace
F3                  Next match
Shift-F3            Previous match
F4                  Jump to source
Ctrl-Alt-Shift-T    Refactor this
F5                  Refactor copy
F6                  Refactor move
Ctrl-F6             Refactor change signature
Shift-F6            Refactor rename
Alt-Delete          Refactor safe delete
Ctrl-Alt-V          Refactor extract variable
Ctrl-Alt-F          Refactor extract field
Ctrl-Alt-P          Refactor extract parameter
Ctrl-Alt-M          Refactor extract method
Ctrl-Alt-N          Refactor inline

Java EE应用，同时部署在两个Tomcat(5.5.27)实例上，前面放了个Apache(httpd-2.2.19-win32-x86-no_ssl)，通过mod_jk(1.2.32)做负载均衡，同一台物理服务器，操作系统为64位的Windows Server 2003 SP2。现象是60+客户端，平均每个客户端每秒请求数2次，单个请求正常响应时间在500ms以内，即每秒冲进来120个请求，并发量最多在60上下，Apache就已不堪"重"负，静态资源响应时间都超过10s，同时Tomcat和数据库服务器均正常。凭我的经验，同样的压力直接压到Tomcat也不至于这么难看。看来问题出在Apache。

首先修改httpd.conf配置文件，打开status模块：

LoadModule status_module modules/mod_status.so
<Location /status>
  SetHandler server-status
  Order deny,allow
  Deny from all
  Allow from 127.0.0.1 #需要的话也可放开为all
</Location>

这样我们就能通过/status页面查看服务器当前的状态信息，结果观察到worker(即线程)数仅为64！坑爹啊！难怪撑不住。我记得以前Windows下面的Apache默认线程数没这么小的。找准问题，接下来就好办了：

<IfModule mpm_winnt.c>
  ThreadsPerChild 300
  MaxRequestsPerChild 0
</IfModule>

稍微解释一下：mpm_winnt.c是Apache为Windows NT提供的MPM (Multi-Processing Module)，对应到Linux环境下，则有prefork.c(多进程/每进程1个线程)和worker.c(多进程+多线程)两种MPM可选。Windows下面只会有父与子两个进程，因此单个子进程能同时起多少线程(ThreadsPerChild)就成了调优的关键。另一个参数MaxRequestsPerChild的含义是单个子进程累计最多处理到少个请求，超过该值则退出重启，这是出于防止内存泄露慢慢拖垮整个服务器而做的防御性措施，0表示不做此限制。

新配置上线后，客户端数量顺利冲上200+。Case closed.

今天帮同事解决一个邮件乱码的问题，简记于此。

邮件正文就不贴了，有一段从上下文判断明显应该是"上海"，却显示成了"涓..."，于是自然而然的拿出"上"字和"涓"字来分析。

通过简单的Groovy脚本对这两个汉字分别按gbk和utf-8编码，并将得到的byte[]转换成二进制表示输出如下：

== 上 ==
11001001 11001111
11100100 10111000 10001010
== 涓 ==
11100100 10111000
11100110 10110110 10010011


注意"上"字的第2排前两组和"涓"字第1排的两组byte正好相同，于是问题迎刃而解，乱码是由于邮件以utf-8编码后被错误的以gbk解码（随后又重新编码成utf-8）造成的。

关键代码：

void showBytes(String input) {
  println("== " + input + " ==")
  b = input.getBytes("gbk")
  b.each { print Integer.toBinaryString(it).substring(24) + ' ' }
  println()
  b = input.getBytes("utf8")
  b.each { print Integer.toBinaryString(it).substring(24) + ' ' }
  println()
}


和Swing应用的直接跨平台不同，SWT/RCP应用要想同时支持不同平台，需要做些特殊的配置，不过并不复杂，记录在此，希望能帮到有需要的朋友。目前win32、32位Linux、64位Linux和Mac OS X基本上就覆盖了所有主流的桌面操作系统，本文将以同时支持这四种OS为例来进行讲解。

首先是下载对应版本的RCP框架在不同操作系统的插件，将它们放在同一个plugins目录，比如你可以用win32为基础，然后添加针对其他平台的如下插件:

org.eclipse.core.filesystem
org.eclipse.core.filesystem.win32.x86
org.eclipse.core.filesystem.linux.x86
org.eclipse.core.filesystem.linux.x86_64
org.eclipse.core.filesystem.macosx

org.eclipse.core.net
org.eclipse.core.net.win32.x86
org.eclipse.core.net.linux.x86

org.eclipse.core.resources
org.eclipse.core.resources.win32.x86

org.eclipse.equinox.launcher
org.eclipse.equinox.launcher.win32.win32.x86
org.eclipse.equinox.launcher.gtk.linux.x86
org.eclipse.equinox.launcher.gtk.linux.x86_64
org.eclipse.equinox.launcher.carbon.macosx

org.eclipse.equinox.security
org.eclipse.equinox.security.win32.x86
org.eclipse.equinox.security.macosx

org.eclipse.swt
org.eclipse.swt.win32.win32.x86
org.eclipse.swt.gtk.linux.x86
org.eclipse.swt.gtk.linux.x86_64
org.eclipse.swt.carbon.macosx

接下来将不同平台下的eclipse可执行文件(Windows下面是eclipe.exe，Linux下是eclipse，Mac OS X下面是Eclipse.app)放到不同的子目录下，当然，如果你的RCP应用有别的名称，也可以重命名eclipse可执行文件，按照不同平台的规范更换图标，然后修改.ini文件让它的-startup和-startup.libraray参数指向相对路径中正确版本的插件即可。

最后分享一下我们软件部署的机制: 按照前面介绍的方式打包的应用程序，交到用户手里并不是很友好，因为需要他/她自己再做一次判断，当前的操作系统是什么，然后打开不同的目录去点击不同的可执行文件。我们的做法是单独提供一个Swing程序，在客户端自动判断OS，然后自动调用不同版本的可执行文件，同时，这个Swing程序被做成Java Web Start，把整个RCP客户端的下载和同步也处理掉，这样，对用户而言，整个过程就透明了，只需要一个JNLP，剩下的工作完全自动化。

在Linux或其他UNIX和类UNIX环境下，ps命令想必大家都不陌生，我相信也有不少同学写过 ps aux | grep java | grep -v grep | awk '{print $2}' 这样的管道命令来找出Java进程的pid。常言道，Java并非真的"跨平台"，它自己就是平台。作为平台，当然也有些基本的工具，让我们可以用更简单、更统一，同时又是非侵入的方式来查询进程相关信息。今天我们就来认识一下其中的两个。

jps

顾名思义，它对应到UNIX的ps命令。用法如下:

jps [ options ] [ hostid ]

其中，options可以用 -q (安静) -m (输出传递给main方法的参数) -l (显示完整路径) -v (显示传递给JVM的命令行参数) -V (显示通过flag文件传递给JVM的参数) -J (和其他Java工具类似用于传递参数给命令本身要调用的java进程)；hostid是主机id，默认localhost。

jstat

用于输出给定java进程的统计信息。用法如下:

jstat -options 可以列出当前JVM版本支持的选项，常见的有 -class (类加载器) -compiler (JIT) -gc (GC堆状态) -gccapacity (各区大小) -gccause (最近一次GC统计和原因) -gcnew (新区统计) -gcnewcapacity (新区大小) -gcold (老区统计) -gcoldcapacity (老区大小) -gcpermcapacity (永久区大小) -gcutil (GC统计汇总) -printcompilation (HotSpot编译统计)

假定你要监控的Java进程号是12345，那么
jstat -gcutil -t 12345 200 300 即可每200毫秒连续打印300次带有时间戳的GC统计信息。

简单解释一下: -gcutil是传入的option；必选，-t是打印时间戳，是以目标JVM启动时间为起点计算的，可选；12345是vmid/pid，和我们从jps拿到的是一样的，必选；200是监控时间间隔，可选，不提供就意味着单次输出；300是最大输出次数，可选，不提供且监控时间间隔有值的话，就是无限期打印下去。

具体输出明细的解释请参考官方文档 http://download.oracle.com/javase/6/docs/technotes/tools/share/jstat.html

代码是从guithub的gist上抄的，简单改了改，原始代码见: http://gist.github.com/66925

这段代码解决的是经典的汉诺塔问题，通过一根中柱，将左柱上64个大小依次叠加的圆盘全部移动到右柱，要求整个过程中每次只能移动一个圆盘，且每个圆盘只能独立占据一根柱子或是叠加在比自身更大的圆盘上。

简单分析一下就知道，这是一个递归问题(FP的英雄特长)：

• 当只有1个圆盘时，不用通过中柱，直接可以从左柱移动到右柱；
• 当有2个圆盘时，将小盘移动到中柱，剩下的大盘移动到右柱，再从中柱把小盘移动到右柱；
• 当有3个圆盘时，先移动2个圆盘到中柱，再移动大盘到右柱，再移动2个圆盘到右柱；
• ...

很容易发现一个pattern，那就是移动N(N>1)个圆盘，可以通过以下三个步骤：

1. 移动N-1个圆盘，从左柱到中柱；
2. 移动剩下的1个圆盘，从左柱到右柱；
3. 移动N-1个圆盘，从中柱到右柱。

在解释代码之前，先说说Scala的implicit隐式转换，这是一个非常powerful的idea，当Scala编译器发现类型不匹配，它不会直接fail，而是尝试从代码中指定的，在scope内的implicit转换定义，来替换问题对象或表达式以满足类型要求，当然，为了避免歧义，同一时刻Scala需要找到唯一的一个满足条件的implicit定义。

我们的代码首先定义了一个取得友好类名的方法，不去深究它，然后定义了一个正整数的序列，也不去深究它了，你只需要当作他们是正整数就好，接触过FP的同学应该对此类定义不陌生，接下来定义了如下3个支持implicit传入参数的方法：

1. implicit def move1[A,B,C](implicit a:Manifest[A], b:Manifest[B]) : Move[_1,A,B,C]
2. implicit def moveN[P<:Num,A,B,C]( implicit
   m1:Move[P,A,C,B],
   m2:Move[_1,A,B,C],
   m3:Move[P,C,B,A]
   ) : Move[Succ[P],A,B,C]
3. def run[N<:Num,A,B,C](implicit m:Move[N,A,B,C])

含义分别是：

1. 当需要Move[_1,A,B,C]值时，可以找我帮忙(我有个side-effect，那就是输出移动指令)；
2. 当需要Move[Succ[P],A,B,C]时，可以找我帮忙；
3. 运行我，我接受Move[N,A,B,C]类型的参数。

简单说明：Scala用[]表示类型参数，区别于Java的<>，另外，Scala的类型声明在变量/函数定义之后。Move[_,A,B,C]的含义是通过C，从A移动圆盘到B。

我们来模拟运行一下，为了演示效果，用一个中等复杂的数目，3个圆盘，从Left移动到Right。

run[_3,Left,Right,Center]，对应Move[Succ[_2],Left,Right,Center]，于是展开成三个Move：

Move[_2,Left,Center,Right]即Move[Succ[_1],Left,Center,Right]
Move[_1,Left,Right,Center]
Move[_2,Center,Right,Left]即Move[Succ[_1],Center,Right,Left]

然后继续展开Move[_2,Left,Center,Right]和Move[_2,Center,Right,Left]，得到：

Move[_1,Left,Right,Center]
Move[_1,Left,Center,Right]
Move[_1,Right,Center,Left]
--------------------------
Move[_1,Left,Right,Center]
--------------------------
Move[_1,Center,Left,Right]
Move[_1,Center,Right,Left]
Move[_1,Left,Right,Center]

这个时候已经全部都匹配Move[_1,A,B,C]，于是我们很容易得到以下输出：

Move from Left to Right
Move from Left to Center
Move from Right to Center
Move from Left to Right
Move from Center to Left
Move from Center to Right
Move from Left to Right

希望本文能带给Scala初学者一些感性认识和启发。

1. Sun没有意识到这样一个事实：任何一款桌面框架的实现，假如不能无缝的运行在Windows上，都注定成为“也能运行”的一种GUI技术，始终无法和native的版本抗衡。
2. 他们认定解决（实现）高级桌面控件的方法是通过Swing这种方式，为了“跨平台”，所有东西本质上都是通过JFrame自己在canvas上画，而不是利用现成已经实现的东西，带来额外的开销和重复劳动。
3. 他们早应该把官方的开发工具做得更加完善，现在NetBeans发展很好，但是不是有点太晚意识到这个问题了，而不论OS X还是Windows，都在这方面积累了一大批忠实用户。