更新时间： 2015/06/16

这次JDK 8 一共带来了55个新特性，目前所有API应该都已经冻结， 正在进行零bug测试。这次更新的力度比JDK 6/JDK 7都要大，延期了几次，也非常令人期待。 我个人准备花费几个月的学习时间，努力跟上Java 8的发布节奏。当然由于对Java 7不太熟悉，因此同时也学习下Java 7的API。

目前支持JDK 8的IDE有：

• Netbeans 7.4
• IDEA 12
• 非官方的Eclipse, 官方需要到明年Java 8正式发布以后

并非所有JDK 8的特性IDE都能支持，因此需要随时更新IDE以便获得更好的开发环境，推荐使用IDEA。

Java 8 新特性入门

1. 时间表
2. Lambda
3. 流式操作 – Stream API
4. 接口默认方法 – Default Method
5. 日期和时间 – Date & Time (JSR 310)
6. 集合扩展 – Collections API
7. 并发操作 – Concurrency API additions
8. IO/NIO 扩展 – IO/NIO API additions
9. 反射和注解更新 – Reflection and annotation changes
10. Base64
11. 其它各种更新 – Other additions

Java 7 新特性入门

1. 字符串在switch中的使用
2. try-with-resources 自动释放资源
3. 泛型实例创建的类型推断
4. 多异常catch操作
5. 文件API扩展
6. 集合API更新
7. 并发编程API更新
8. Unicode 6.0的支持
9. JDBC 4.1 支持 RowSet 1.1

[更新时间: 2013/10/16]
[原文地址：Java 8 入门/新特性]

    cat  ~/bin/png2jpg
    #!/bin/bash
    # convert png files to jpeg files
    # usage: png2jpg <file>

    for f in "$@"
    do
        sips -s format jpeg --out "${f%.*}.jpg" "$f"
    done

    cat ~/bin/jpg2png
    #!/bin/bash
    # convert jpeg files to png files
    # usage: jpg2png <file>

    for f in "$@"
    do
        sips -s format png --out "${f%.*}.png" "$f"
    done

1. sips doc
2. Resizing images using the command line
3. Shell Parameter Expansion
4. Extract filename and extension in bash
   

public interface Runnable {

    public abstract void run();
}

那么如果 run() 方法中抛出了RuntimeException，将会怎么处理了？

通常java.lang.Thread对象运行设置一个默认的异常处理方法：

java.lang.Thread.setDefaultUncaughtExceptionHandler(UncaughtExceptionHandler)

而这个默认的静态全局的异常捕获方法时输出堆栈。

当然，我们可以覆盖此默认实现，只需要一个自定义的java.lang.Thread.UncaughtExceptionHandler接口实现即可。

public interface UncaughtExceptionHandler {

    void uncaughtException(Thread t, Throwable e);
}

而在线程池中却比较特殊。默认情况下，线程池 java.util.concurrent.ThreadPoolExecutor 会Catch住所有异常， 当任务执行完成(java.util.concurrent.ExecutorService.submit(Callable))获取其结果 时(java.util.concurrent.Future.get())会抛出此RuntimeException。

/**
 * Waits if necessary for the computation to complete, and then
 * retrieves its result.
 *
 * @return the computed result
 * @throws CancellationException if the computation was cancelled
 * @throws ExecutionException if the computation threw an exception
 * @throws InterruptedException if the current thread was interrupted while waiting
 */
V get() throws InterruptedException, ExecutionException;

其中 ExecutionException 异常即是java.lang.Runnable 或者 java.util.concurrent.Callable 抛出的异常。

也就是说，线程池在执行任务时捕获了所有异常，并将此异常加入结果中。这样一来线程池中的所有线程都将无法捕获到抛出的异常。 从而无法通过设置线程的默认捕获方法拦截的错误异常。

也不同通过自定义线程来完成异常的拦截。

好在java.util.concurrent.ThreadPoolExecutor 预留了一个方法，运行在任务执行完毕进行扩展（当然也预留一个protected方法beforeExecute(Thread t, Runnable r)）：

protected void afterExecute(Runnable r, Throwable t) { } 

此方法的默认实现为空，这样我们就可以通过继承或者覆盖ThreadPoolExecutor 来达到自定义的错误处理。

解决办法如下：

ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(11, 100, 1, TimeUnit.MINUTES, //
        new ArrayBlockingQueue<Runnable>(10000),//
        new DefaultThreadFactory()) {

    protected void afterExecute(Runnable r, Throwable t) {
        super.afterExecute(r, t);
        printException(r, t);
    }
};

private static void printException(Runnable r, Throwable t) {
    if (t == null && r instanceof Future<?>) {
        try {
            Future<?> future = (Future<?>) r;
            if (future.isDone())
                future.get();
        } catch (CancellationException ce) {
            t = ce;
        } catch (ExecutionException ee) {
            t = ee.getCause();
        } catch (InterruptedException ie) {
            Thread.currentThread().interrupt(); // ignore/reset
        }
    }
    if (t != null)
        log.error(t.getMessage(), t);
}

此办法的关键在于，事实上 afterExecute 并不会总是抛出异常 Throwable t，通过查看源码得知，异常是封装在此时的Future对象中的， 而此Future对象其实是一个java.util.concurrent.FutureTask的实现，默认的run方法其实调用的 java.util.concurrent.FutureTask.Sync.innerRun()。

这里我们可以看到它吃掉了异常，将异常存储在java.util.concurrent.FutureTask.Sync的exception字段中：

/** The exception to throw from get() */
private Throwable exception;

当我们获取异步执行的结果时， java.util.concurrent.FutureTask.get()

public V get() throws InterruptedException, ExecutionException {
    return sync.innerGet();
}

java.util.concurrent.FutureTask.Sync.innerGet()

V innerGet() throws InterruptedException, ExecutionException {
    acquireSharedInterruptibly(0);
    if (getState() == CANCELLED)
        throw new CancellationException();
    if (exception != null)
        throw new ExecutionException(exception);
    return result;
}

异常就会被包装成ExecutionException异常抛出。

也就是说当我们想线程池 ThreadPoolExecutor(java.util.concurrent.ExecutorService)提交任务时， 如果不理会任务结果（Feture.get()），那么此异常将被线程池吃掉。

<T> Future<T> submit(Callable<T> task);
Future<?> submit(Runnable task);

而java.util.concurrent.ScheduledThreadPoolExecutor是继承ThreadPoolExecutor的，因此情况类似。

结论，通过覆盖ThreadPoolExecutor.afterExecute 方法，我们才能捕获到任务的异常（RuntimeException）。

原文地址：http://imxylz.com/blog/2013/08/02/handling-the-uncaught-exception-of-java-thread-pool/

File - 基础文件操作

FEB 24TH, 2013

学习一门语言，我总是喜欢从文件开始。文本文件的读写操作是我比较在意的基本功能。 在这方面，Java语言功能比较强大，用到的设计模式也非常多。只是使用起来太过繁琐。 而Python在这方面表现非常好，简洁不失功能，强大不失性能，通俗不失优雅，值得称赞。

我们从一个最简单的开始。

with open('/etc/resolv.conf') as f:
   print(f.read()) 

这里有用到with语法来关闭文件句柄。

open()

首先来了解下open()内置函数。

open(file, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True, opener=None)
   Open file and return a corresponding file object. If the file cannot be opened, an OSError is raised. 

open()的参数众多，通常需要关注的是mode/encoding/errors/newline等。

最佳实践

(1) 读取文件必须传入字符编码encoding 
(2) 用完的流需要关闭，推荐使用with操作 
(3) 换行符尽可能的使用UNIX格式(\n)，尽管python可以智能转换 
(4) 如果可以的话尽可能的使用utf-8编码来处理非ascii字符，不要依赖操作系统的编码 

小贴士

多个文件同时操作可使用with的语法：

with open('/etc/hosts','r') as f,open('/tmp/hosts','w') as t:
   //do something 

或者

with f=open('/etc/hosts'),t=open('/tmp/hosts','w'):
   // do something 

file object

文件对象描述的是一种“流”操作，通常支持read()或者write()方法。 这里的文件对象是一种概念上的“文件对象”，除了常见的真是的磁盘文件，还可以是 标准输入输出文件(stdin/stdout/stderr)，内存缓冲区(StringIO,cStringIO)， socket，pipes等。

这在io模块中有具体的描述。

文本操作和二进制操作有一些区别。分别介绍。

Text I/O

如果mode中包含t（默认），那么返回的流是一个纯文本操作。

read() 是读取文本的最简单的方法。返回的是字符串形式的结果（和参数encoding有关）。

read(n)
 Read and return at most n characters from the stream as a single str. If n is negative or None, reads until EOF. 

在很多安装脚本中有：

readme=open('./README.md').read() 

类似的用法。这在一个快速结束的程序中问题不大。在正式的服务中应该随时关闭文件句柄释放资源。

小贴士：

如果已经读取到文件末尾，read()则返回空字符串''。 

如果要读取一行，使用readline()方法。

readline(limit=-1)
 Read until newline or EOF and return a single str. If the stream is already at EOF, an empty string is returned. If limit is specified, at most limit characters will be read. 

读取一行意味着和行结束符有关，这个有点复杂。

读取多行，使用readlines()方法。这将返回一个字符串列表。readlines()也可以限制最多读取多少个字符。

小贴士：

readline(limit=-1)和readlines(limit=-1)对limit的描述不太一致。 
readline(limit=-1)描述的是读取一行，最多不超过limit个字符（不是字节），因此有可能结果不是某一行的结束。 
readlines(limit=-1)描述的是读取字符，直到limit个字符所在的行结束。也就是返回的结果一定是某一行的结束(除非EOF)。 

例如：
>>> open('/tmp/x1','w').write('Python真是一个好同学\n只是限制被割裂成两个版本了\n我支持python3.x')
 40 
>>> open('/tmp/x1','r').readline(10)
 'Python真是一个' 
>>> open('/tmp/x1','r').readlines(10)
 ['Python真是一个好同学\n'] 

readlines(limit)是一个难以理解的逻辑。如果可以不要随便传输一个参数。参考这里。

写入文本可使用write(s)方法：

write(s) Write the string s to the stream and return the number of characters written. 

写入的是字符串，而不是字节。如果要写入多行字符串，可以使用writelines(lines)方法。

小贴士：

write(s)和writelines(lines)不会将行结束符写入文件流。因此需要手动写入行结束符。 

Binary I/O

二进制流和文本流类似，只是二进制流没有encoding一说。打开二进制流需要传入参数mode中包含’b’。

例如：

>>> type(open('/etc/hosts','rb').read())
 <class 'bytes'> 

对比文本流，二进制流有一些小的差别：

• read()返回的值是字节(bytes)
• readline()返回的值是字节(bytes)，包括换行符
• readlines()返回的值是字节(bytes)列表，包括换行符
• write()参数可以是bytes或者bytearray
• readinto(b)是将内容读取到bytearray b中，返回读取的字节数。

其它文件操作

除了read/write方法，文件对象还有一些其它的内置方法：

• file.close() 关闭文件
• file.fileno() 获取文件描述符（整形值）
• file.flush() 对于有缓冲区的写操作，刷新缓冲区
• file.tell() 返回当前流的字节位置
• file.seek() 移动文件流的当前位置
• file.truncate() 截断文件大小

将在I/O介绍更多的知识。

~ $ ls ~/.jrebel/jrebel.lic 

/Users/adyliu/.jrebel/jrebel.lic

下载地址

• 4.0 http://www.blogjava.net/xylz/archive/2011/06/12/352109.html
• 5.1.0 /Files/xylz/jrebel.jar.zip
• 5.1.2 /Files/xylz/jrebel-5.1.2.zip
• 5.2.0 jrebel-5.2.0-crack.zip
• 5.2.2 jrebel-5.2.2-crack.zip
• 5.3.0 jrebel-5.3.0-crack.zip
• 5.3.1 jrebel-5.3.1-crack.zip
• 5.3.2 jrebel-5.3.2-crack.zip
  

Updated 2013/03/25
    JRebel更新到5.2.0版本，所以可以放出一个低版本（我一直使用）5.1.2。5.1.3就暂时不去解决了。

关键词： JRebel 5.3.1 crack, JRebel 5.3.0 crack, JRebel 5.2.2 crack, JRebel 5.2.0 crack, JRebel 5.1.2 crack,JRebel 5.1.0 crack, JRebel 5.x crack

下载SQLite3

我们下载sqlite源码包，只需要其中的sqlite3.c、sqlite.h即可。

最简单的一个创建表操作

在这个操作中我们执行了如下操作：

• 打开数据库
• 执行SQL语句
• 关闭数据库

当然这中间会有一些状态的判断以及内存指针的释放等。

打开数据库的API如下：

打开数据库除了这种形式意外，还有sqlite3_open、sqlite3_open16、sqlite3_open_v2几种形式，基本上类似。

大部分sql操作都可以通过sqlite3_exec来完成，它的API形式如下：

各个参数的意义为：

• sqlite3描述的是数据库句柄
• sql 要执行的SQL语句
• callback回调函数
• void *回调函数的第一个参数
• errmsg错误信息，如果没有SQL问题则值为NULL

回调函数式一个比较复杂的函数。它的原型是这样的:

每一个参数意义如下：

• params是sqlite3_exec传入的第四个参数
• column_size是结果字段的个数
• column_value是返回记录的一位字符数组指针
• column_name是结果字段的名称

通常情况下callback在select操作中会使用到，尤其是处理每一行记录数。返回的结果每一行记录都会调用下“回调函数”。 如果回调函数返回了非0，那么sqlite3_exec将返回SQLITE_ABORT，并且之后的回调函数也不会执行，同时未执行的子查询也不会继续执行。

对于更新、删除、插入等不需要回调函数的操作，sqlite3_exec的第三、第四个参数可以传入0或者NULL。

通常情况下sqlite3_exec返回SQLITE_OK=0的结果，非0结果可以通过errmsg来获取对应的错误描述。

Windows下编译：

D:\home\dev\c>cl /nologo /TC sqlite3-demo.c sqlite3.c 

GCC下编译:

$ gcc -o sqlite3-demo.bin sqlite3-demo.c sqlite3.c 

删除表操作

为了防止垃圾数据，我们在加载数据库的时候删除表操作。

简单的删除操作可以直接使用sqlite3_exec即可。这里不需要回调函数以及回调函数的参数。 当然需要可以关注sqlite3_exec返回的结果是否为SQLITE_OK的值。

    const char *sql_drop_table="drop table if exists t";
    const char *sql_create_table="create table t(id int primary key,msg varchar(128))";

    sqlite3_exec(db,sql_drop_table,0,0,&errmsg);
    sqlite3_exec(db,sql_create_table,0,0,&errmsg);

插入数据

插入第一条数据

返回值ret为SQLITE_OK即操作成功。

插入多条数据，并删除数据

预编译操作

    int i = 0;
    sqlite3_stmt *stmt;
    char ca[255];

    //prepare statement
    sqlite3_prepare_v2(db,"insert into t(id,msg) values(?,?)",-1,&stmt,0);
    for(i=10;i<20;i++){
        sprintf(ca,"HELLO#%i",i);
        sqlite3_bind_int(stmt,1,i);
        sqlite3_bind_text(stmt,2,ca,strlen(ca),NULL);
        sqlite3_step(stmt);
        sqlite3_reset(stmt);
    }
    sqlite3_finalize(stmt);

1. 通过sqlite3_prepare_v2()创建一个sqlite3_stmt对象
2. 通过sqlite3_bind_*()绑定预编译字段的值
3. 通过sqlite3_step()执行SQL语句
4. 通过sqlite3_reset()重置预编译语句，重复操作2多次
5. 通过sqlite3_finalize()销毁资源

sqlite3_prepare_v2()有个多种类似的形式，完整的API语法是：

各个参数的定义为：

• db为sqlite3的句柄
• zSql为要执行的SQL语句
• nByte为要执行语句在zSql中的最大长度，如果是负数，那么就需要重新自动计算
• ppStmt为预编译后的句柄
• pzTail预编译后剩下的字符串（未预编译成功或者多余的）的指针，通常没什么用，传入0或者NULL即可。

绑定参数sqlite3_bind_*有多种形式，分别对应不同的数据类型:

预编译SQL语句中可以包含如下几种形式：

• ?
• ?NNN
• :VVV
• @VVV
• $VVV

NNN代表数字，VVV代表字符串。

如果是?或者?NNN，那么可以直接sqlite3_bind_*()进行操作，如果是字符串，还需要通过sqlite3_bind_parameter_index()获取对应的index，然后再调用sqlite3_bind_*()操作。这通常用于构造不定条件的SQL语句（动态SQL语句）。

查询操作

回调函数的解释参考最上面的描述。 首先声明一个回调函数。

int print_record(void *,int,char **,char **); 

查询代码

现在定义回调函数，只是简单的输出字段值。

不使用回调的查询操作

定义使用的变量

 char **dbresult; int j,nrow,ncolumn,index; 

查询操作

sqlite3_get_table的API语法：

其中：

• db是sqlite3的句柄
• zSql是要执行的sql语句
• pazResult是执行查询操作的返回结果集
• pnRow是记录的行数
• pnColumn是记录的字段个数
• pzErrmsg是错误信息

由于sqlite3_get_table是sqlite3_exec的包装，因此返回的结果和sqlite3_exec类似。

pazResult是一个(pnRow+1)*pnColumn结果集的字符串数组，其中前pnColumn个结果是字段的名称，后pnRow行记录是真实的字段值，如果某个字段为空，则对应值为NULL。

最后需要通过sqlite3_free_table()释放完整的结果集。

更新操作

 sqlite3_exec(db,"update t set msg='MESSAGE#10' where id=10",NULL,NULL,&errmsg); 

当然了，我们也可以使用预编译方法进行更新操作。

受影响的记录数

我们可以使用sqlite3_change(sqlite3 *)的API来统计上一次操作受影响的记录数。

 ret = sqlite3_exec(db,"delete from t",NULL,NULL,&errmsg); 

if(ret == SQLITE_OK){

printf("delete records: %i\n",sqlite3_changes(db));

} 

总结

这里我们接触了SQLITE3的13个API：

• sqlite3_open()
• sqlite3_exec()
• sqlite3_close()
• sqlite3_prepare_v2
• sqlite3_bind_*()
• sqlite3_bind_parameter_index()
• sqlite3_step()
• sqlite3_reset()
• sqlite3_finalize()
• sqlite3_get_table
• sqlite3_change()
• sqlite3_free()
• sqlite3_free_table()

事实上截止到SQLITE3.7.14(2012/09/03) 一共提供了204个API函数（http://www.sqlite.org/c3ref/funclist.html）。

但最精简的API函数大概有6个：

• sqlite3_open()
• sqlite3_prepare()
• sqlite3_step()
• sqlite3_column()
• sqlite3_finalize()
• sqlite3_close()

核心API也就10个（在精简API基础上增加4个）：

• sqlite3_exec()
• sqlite3_get_table()
• sqlite3_reset()
• sqlite3_bind()

因此掌握起来还是比较容易的。

完整的源码地址： https://gist.github.com/3780669

• 增加创建Topic的命令 Issues 4
• 增加监控Topic消费情况的工具 Issues 5
• 添加删除Topic的命令 Issues 7
• 忽略IntelliJ IDEA工程文件 Issues 6
• 支持密码验证某些操作 Issues 8
• 手动配置broker时支持默认分区数配置 Issues 9
• 重构发送消息的接口 Issues 10
• 添加一个默认发送字符串的消息发送者 Issues 11
• 添加生成完整完整包的脚本 Issues 12
• 添加一个导出字符串消息的脚本工具 Issues 13
• 修复消费自动分配（负载均衡）失败的问题 Issues 14

Fedora 17发布，第二天立马更新了。 首先光是更新就折腾了很久，总算弄好了。结果发现一个巨大的问题。gtk2与eclipse不兼容。

不兼容的后果是总是报这样的错误（命令行启动eclipse： eclipse -debug -consolelog）：

(Eclipse:21798): GLib-GIO-CRITICAL **: g_dbus_proxy_new_for_bus_sync: assertion `g_dbus_is_name (name)' failed

(Eclipse:21798): GLib-GIO-CRITICAL **: g_dbus_proxy_new_for_bus_sync: assertion `g_dbus_is_name (name)' failed

(Eclipse:21798): GLib-GIO-CRITICAL **: g_dbus_proxy_new_for_bus_sync: assertion `g_dbus_is_name (name)' failed

表现为打开编辑器后总是有很多内容无法显示，显示为空白，必须重新选定或者拖动滚动条才能显示。

这令人崩溃啊！！！

这下悲剧了，要知道我的开发工作就是在ecilpse下进行的。

好吧，上网找找。发现有些人也遇到不兼容问题。但是没有一个解决办法。

我的解决过程是这样：

• 更新整个fedora环境（发布后官方发布了一些紧急修正包），未果
• 重新下载最新发行版的eclipse，未果
• 重新下载最新的测试版本eclipse，未果
• 下载fedora18的gtk2、glibc等强制安装，未果
• 降级gtk2、glibc等到fedora 16，未果
• 继续google，寻找解决方法，依然未果
• 替换最新发布的二进制swt库，未果
• 尝试手动编译swt源码，未成功

这样，折腾了几天，快要放弃了。

昨天是在搞不定，尝试下载Idea的社区版，使用了下还是感觉不习惯，放弃。

今天早上突然想到，公司配的那台笔记本还是Fedora 16未升级。于是想强制降级到swt所有依赖库到Fedora 16看能否解决问题。

使用了下面命令成功完成了部分依赖库的降级，这里面更是不断的尝试，在失败中成长。哭~~~

yum list

yum install

yum erase

yum --releasever=16 downgrade

rpm -qa

rpm -qf

ldd

lsof

好在只是用了mirrors.sohu.com镜像，绑定了内网地址，下载rpm包非常快。这是是给我最大的安慰。

这个过程经过了长达两个小时的折腾和仿佛。最终终于成功完成了以下依赖的降级。

[adyliu@adyliu-pc jafka]$ rpm -qa|grep fc16|sort
cscope-15.7a-9.fc16.x86_64
dconf-0.10.0-1.fc16.x86_64
fcitx-4.2.3-1.fc16.x86_64
fcitx-data-4.2.3-1.fc16.noarch
fcitx-gtk2-4.2.3-1.fc16.x86_64
fcitx-gtk3-4.2.3-1.fc16.x86_64
fcitx-libs-4.2.3-1.fc16.x86_64
gdk-pixbuf2-2.24.1-1.fc16.x86_64
gedit-3.2.6-1.fc16.x86_64
glib2-2.30.3-1.fc16.x86_64
glibc-2.14.90-24.fc16.7.x86_64
glibc-common-2.14.90-24.fc16.7.x86_64
glibc-devel-2.14.90-24.fc16.7.x86_64
glibc-headers-2.14.90-24.fc16.7.x86_64
glib-networking-2.30.1-2.fc16.x86_64
gnome-disk-utility-libs-3.0.2-3.fc16.x86_64
gnutls-2.12.14-2.fc16.x86_64
gsettings-desktop-schemas-3.2.0-1.fc16.noarch
gtk2-2.24.8-3.fc16.x86_64
gtk2-immodule-xim-2.24.8-3.fc16.x86_64
gvfs-1.10.1-3.fc16.x86_64
libarchive-2.8.5-1.fc16.x86_64
libbluray-0.2-0.5.20110710git51d7d60a96d06.fc16.x86_64
libcdio-0.82-6.fc16.x86_64
libsoup-2.36.1-2.fc16.x86_64
mdadm-3.2.3-7.fc16.x86_64
nautilus-3.2.1-2.fc16.x86_64
nautilus-extensions-3.2.1-2.fc16.x86_64
PackageKit-0.6.22-2.fc16.x86_64
PackageKit-glib-0.6.22-2.fc16.x86_64
PackageKit-gtk-module-0.6.22-2.fc16.x86_64
PackageKit-yum-0.6.22-2.fc16.x86_64
pango-1.29.4-1.fc16.x86_64
yum-3.4.3-24.fc16.noarch

可以看到仅仅更新gtk2/glibc是不够的。

总结下：

• 坚持是成功的关键（中间过程，欲哭无泪，最后我都打算重新安装Fedora 16了）
  
• 我还是很强的（囧）
  
  
  

创建slice文件

转换slice

服务端

客户端

所有文件

• 消息持久化非常快，服务端存储消息的开销为O(1)，并且基于文件系统，能够持久化TB级的消息而不损失性能
• 吞吐量很大，在我的单机DELL E6220（现已经停产）、Fedora 16 x86_64下单CPU内核运行，使用Jafka内置的python客户端，吞吐量能够达到300k/s
• 完全的分布式系统，broker、producer、consumer都原生自动支持分布式。自动实现复杂均衡。
• 内核非常小，整个系统（包括服务端和客户端）只有一个272KB的jar包，内部机制也不复杂，适合进行内嵌或者二次开发 。整个服务端加上依赖组件共3.5MB。
• 消息格式以及通信机制非常简单，适合进行跨语言开发。目前自带的Python 3.x的客户端支持发送消息和接收消息。

1. [深入浅出Jetty 01] Jetty 8.x 安装
2. [深入浅出Jetty 02] Jetty 8.x 简单试用
3. [深入浅出Jetty 03] 简单的RESTful入门
4. [深入浅出Jetty 04] Jetty的启动方式
5. [深入浅出Jetty 05] Jetty 模块化

运行方式

运行方法1

[adyliu@adyliu-pc jetty8]$ curl -v http://127.0.0.1:8080
* About to connect() to 127.0.0.1 port 8080
*   Trying 127.0.0.1 connected
* Connected to 127.0.0.1 (127.0.0.1) port 8080
> GET / HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: 127.0.0.1:8080
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Wed, 28 Mar 2012 08:15:27 GMT
< Content-Type: text/html
< Content-Length: 618
< Server: Jetty(8.1.2.v20120308)
<HTML>
<HEAD>
<TITLE>Error 404 - Not Found</TITLE>
<BODY>
<H2>Error 404 - Not Found.</H2>

运行方法2

运行方法3

命令参数

start.config的作用有以下几个：

• 定义jetty.home属性
• 定义jetty启动类
• 定义jetty启动的默认配置文件
• 定义OPTIONS
• 根据OPTIONS来定义classpath

上面特别提到OPTIONS。什么是OPTIONS？

OPTIONS

由于jetty是高度可定制的，因此jetty将各个模块拆分成各个非常细小的模块。每一个模块（实际上是一个个的jar包），我们可以简单的看出是一个OPTION。而每一个OPTION都会对应于实际的jar，这就决定了这些jar包是否需要加入classpath，并且在jetty启动的时候是否需要做一些额外的事情。

start.config文件的语法也挺有意思的。支持一些简单的逻辑判断，例如文件是否存在、命令行参数是否存在等。

默认情况下有如下配置：

• path参数的值加入classpath
• lib参数的值作为目录搜索jar包，其中的jar/zip包加入classpath
• 默认的启动类是org.eclipse.jetty.xml.XmlConfiguration.class，除非定义了start.class属性
• 默认的jetty配置文件是$(jetty.home)/etc/jetty.xml，除非传入的参数不为空
• 默认${jetty.home}目录是当前目录（不一定是start.jar所在路径）。${jetty.home}属性搜索顺序有：
  • $(jetty.home) 参数或者系统属性（包括环境变量）
  • . 当前路径
  • .. 当前路径的父路径
  • jetty-distribution/src/main/resources 当前路径的发行版子路径
  • ../jetty-distribution/src/main/resources 当前路径的父路径的发行版子路径
• 默认的classpath有：
  • resources
  • lib/jetty-xml-8.1.2.v20120308.jar
  • lib/servlet-api-3.0.jar
  • lib/jetty-http-8.1.2.v20120308.jar
  • lib/jetty-continuation-8.1.2.v20120308.jar
  • lib/jetty-server-8.1.2.v20120308.jar
  • lib/jetty-security-8.1.2.v20120308.jar
  • lib/jetty-servlet-8.1.2.v20120308.jar
  • lib/jetty-webapp-8.1.2.v20120308.jar
  • lib/jetty-deploy-8.1.2.v20120308.jar
  • lib/jetty-servlets-8.1.2.v20120308.jar
  • lib/jetty-util-8.1.2.v20120308.jar
  • lib/jetty-io-8.1.2.v20120308.jar

start.jar参数

我们再来看start.jar支持的参数：

[adyliu@adyliu-pc jetty8]# java -jar start.jar --help
Usage: java -jar start.jar [options] [properties] [configs]

options

其中options列表（这指的是命令行参数，不是模块，由此可见jetty将内置的OPTIONS定义为模块多好）有：

• --version 列出版本号
• --list-options 列出当前start.config支持的所有OPTIONS
• --list-config 列出当前start.config内容（文本内容）
• --dry-run 列出当前配置要启动的java进程完整参数（不启动jetty服务）
• --exec 启动子进程（只有启动子进程才能修改-X，-D等参数，因为start.jar本身就是依靠java进程启动的，不能在运行时改变）
• --stop 停止运行的jetty实例
• --daemon 后台运行jetty，启动将stdout/stderr记录到${jetty.log}/start.log中（好了，这个变量jetty.log没有默认配置说明，估计是${jetty.home}/logs目录）
• --config=<file> 指定特别的start.config，以便覆盖内置的start.config.(经过测试，如果指定此文件，那么内置的配置将不再读取，这导致必须将所有配置写全，包括mainclass/jetty config/OPTIONS等）
• --ini=<file> 从配置文件中装载命令行参数。上面参数以及下面提到的参数是在太多，可以从配置文件中一次性加载，默认的配置文件是${jetty.home}/start.ini。
• --pre=<file> 指定特别的jetty运行配置文件，这个配置文件在后面提高的配置文件前面运行，相当于改变默认的装载机制。

properties

属性分成两种，一种是会传递给系统属性（java.lang.System#getProperty(String)),一种只是作为jetty的启动参数。

如果要传递给系统属性，则格式是： -Dname=value，和java进程系统属性类似。

jetty也有一些默认的系统属性：

jetty的启动参数属性，格式是： name=value，注意这里没有-D了。这些参数不会传递给系统属性。

所有参数列表：

• path=[directory]: 传递额外的classpath，参考上面默认的start.config配置
• lib=[directory]: 传递额外classpath搜索jar/zip的目录
• STOP.PORT=[number]: 停止jetty的端口（远程管理）
• STOP.KEY=[alphanumeric]: 停止jetty的密码（远程管理）
• DEBUG=true: 是否启动调试模式，同时会设置org.eclipse.jetty.util.log.DEBUG属性为true，默认为false
• OPTIONS=[option,option...]: OPTION列表，也就是要启动的模块列表。

在内置的start.config中默认的OPTIONS列表有：

• All
• Client
• Server
• ajp
• annotations
• client
• default
• deploy
• ext
• jmx
• jndi
• jsp
• jta
• monitor
• overlay
• overlays
• plus
• policy
• resources
• rewrite
• security
• server
• servlet
• servlets
• setuid
• webapp
• websocket
• xml

configs

jetty运行需要一些配置文件，这些配置文件对应于不同的OPTION所需要的配置。

默认的jetty配置存在都存在于${jetty.home}/etc中，所有配置文件列表有：

• etc/jetty-ajp.xml
• etc/jetty-annotations.xml
• etc/jetty-bio-ssl.xml
• etc/jetty-bio.xml
• etc/jetty-contexts.xml
• etc/jetty-debug.xml
• etc/jetty-deploy.xml
• etc/jetty-fileserver.xml
• etc/jetty-ipaccess.xml
• etc/jetty-jmx.xml
• etc/jetty-logging.xml
• etc/jetty-monitor.xml
• etc/jetty-overlay.xml
• etc/jetty-plus.xml
• etc/jetty-policy.xml
• etc/jetty-proxy.xml
• etc/jetty-requestlog.xml
• etc/jetty-rewrite.xml
• etc/jetty-ssl.xml
• etc/jetty-stats.xml
• etc/jetty-testrealm.xml
• etc/jetty-webapps.xml
• etc/jetty-xinetd.xml
• etc/jetty.xml

这么多配置，如何记得住？该使用哪些配置？

下一个章节中介绍配置文件。

• [深入浅出Jetty 03] 简单的RESTful入门
• [深入浅出Jetty 02] Jetty 8.x 简单试用
• [深入浅出Jetty 01] Jetty 8.x 安装

    InputStream in = 
    ByteArrayOutputStream baos = new ByteArrayOutputStream(8192);
    int len = -1;
    byte[] b = new byte[8192];//8k
    while ((len = in.read(b)) > 0) {
        baos.write(b, 0, len);
    }
    baos.close();//ignore is ok
    String response =  new String(baos.toByteArray(), encoding);

• 团队更需要合作，按照规范来进行。自造轮子不是不可以，但是生产环境还是要限于自己熟悉的方式。
• 即使非常简单的代码，也有可能有致命的陷阱在里面。善于思考才是王道。
• 学习开源的代码和常规思路，学习解决问题的常规做法。这个问题其实非常简单，熟悉输入输出流的人非常熟练就能解决问题。

文件列表

包含如下文件：

• git忽略文件
• README文件
• pom文件
• 一个简单的Controller文件
• 一个log4j的配置文件
• 一个简单的spring mvc配置
• 一个简单的web.xml

Maven配置

web.xml

dispatcher-servlet.xml

Controller

Access

Resources

• Source code: git@github.com:adyliu/jetty-rest-demo.git (branch: v1.0-helloworld)
• Jetty Maven Plugin: http://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin
• Spring MVC: http://static.springsource.org/spring/docs/3.1.1.RELEASE/spring-framework-reference/html/mvc.html

运行

安装好了以后，在jetty的主目录下，运行起来。

java -jar start.jar 

如果仔细看的话还有一个start.ini，这是典型的eclipse启动方式。事实上jetty8是按照eclipse的OSGI启动模型来运行的。

远程访问

默认情况下jetty使用8080端口，访问下看看。

http://adyliu-pc:8080 

出现了点问题。启动后居然是jetty7后的描述信息。看来jetty8发布的时候比较粗糙，这些细节都没有处理好。事实上，官方站点上的文章都是和jetty7.x有关的，没有更新到8.x版本。

好在有一行提示说，如果要远程访问的话，需要开启一个设置。好吧，按照说明，将默认test.war的远程访问模式打开。 修改文件$JETTY_HOME/contexts/test.d/override-web.xml中的如下部分

这里已经将默认remote的属性值false改为了true。然后再试试。

显然，这样就已经支持远程访问了。

Servlet访问

test.war模块里面有一个dump的Servlet，它可以查看当前请求的Request/Session/Cookie信息。我们简单看一下Request请求。

这里面的信息非常丰富，这为以后调试当前请求信息提供了很方便的样例。

Comet模型

Jetty8.x里面有两种comet模型，一种是常见的长连接(Long Polling), 另一种就是HTML5支持的WebSocket模型。

我们先来简单看一下Long Polling模型。在这种方式下，浏览器定时发起一个长连接，等待服务器返回。一次请求完了以后仍然会发起一个新的请求，总是有一个连接保持双方的通讯。 下图描述了此效果。

而WebSocket模型显然不是所有浏览器都支持的。高版本的Chrome就支持，比如我的chrome 18.0的开发版本就能很好的支持WebSocket。

有意思的是，这里的请求头和响应头有一些特殊的标识。以后涉及到websocket的时候再来研究。

经测试，我机器上的chrome 18.0,firefox 8.0都支持websocket的，而IE9仍然不支持。

最新的发布版本是8.1.0.v20120127，我们从这个版本开始。

JETTY_VERSION=8.1.0.v20120127
wget http://download.eclipse.org/jetty/$JETTY_VERSION/dist/jetty-distribution-$JETTY_VERSION.tar.gz
tar xfz jetty-distribution-$JETTY_VERSION.tar.gz
cd jetty-distribution-$JETTY_VERSION
java -jar start.jar

附录

• 下载地址：http://download.eclipse.org/jetty/8.1.0.v20120127/dist/jetty-distribution-8.1.0.v20120127.tar.gz
• 更多下载安装方式:http://wiki.eclipse.org/Jetty/Starting/Downloads

使用线程的一种说法是为了提高性能。多线程可以使程序充分利用闲置的资源，提高资源的利用率，同时能够并行处理任务，提高系统的响应性。 但是很显然，引入线程的同时也引入了系统的复杂性。另外系统的性能并不是总是随着线程数的增加而总是提高。

性能与伸缩性

性能的提升通常意味着可以用更少的资源做更多的事情。这里资源是包括我们常说的CPU周期、内存、网络带宽、磁盘IO、数据库、WEB服务等等。 引入多线程可以充分利用多核的优势，充分利用IO阻塞带来的延迟，也可以降低网络开销带来的影响，从而提高单位时间内的响应效率。

为了提高性能，需要有效的利用我们现有的处理资源，同时也要开拓新的可用资源。例如，对于CPU而言，理想状况下希望CPU能够满负荷工作。当然这里满负荷工作是指做有用的事情，而不是无谓的死循环或者等待。受限于CPU的计算能力，如果CPU达到了极限，那么很显然我们充分利用了计算能力。对于IO而言（内存、磁盘、网络等），如果达到了其对于的带宽，这些资源的利用率也就上去了。理想状况下所有资源的能力都被用完了，那么这个系统的性能达到了最大值。

为了衡量系统的性能，有一些指标用于定性、定量的分析。例如服务时间、等待时间、吞吐量、效率、可伸缩性、生成量等等。服务时间、等待时间等用于衡量系统的效率，即到底有多快。吞吐量、生成量等用于衡量系统的容量，即能够处理多少数据。除此之外，有效服务时间、中断时间等用于能力系统的可靠性和稳定性等。

可伸缩性的意思是指增加计算资源，吞吐量和生产量相应得到的改进。 从算法的角度讲，通常用复杂度来衡量其对应的性能。例如时间复杂度、空间复杂度等。

Amdahl定律

并行的任务增加资源显然能够提高性能，但是如果是串行的任务，增加资源并不一定能够得到合理的性能提升。 Amdahl定律描述的在一个系统中，增加处理器资源对系统行的提升比率。 假定在一个系统中，F是必须串行化执行的比重，N是处理器资源，那么随着N的增加最多增加的加速比：

理论上，当N趋近于无穷大时，加速比最大值无限趋近于1/F。 这意味着如果一个程序的串行化比重为50%，那么并行化后最大加速比为2倍。

加速比除了可以用于加速的比率外，也可以用于衡量CPU资源的利用率。如果每一个CPU的资源利用率为100%，那么CPU的资源每次翻倍时，加速比也应该翻倍。 事实上，在拥有10个处理器的系统中，程序如果有10%是串行化的，那么最多可以加速1/(0.1+(1-0.1)/10)=5.3倍，换句话说CPU的利用率只用5.3/10=53%。而如果处理器增加到100倍，那么加速比为9.2倍，也就是说CPU的利用率只有个9.3%。

显然增加CPU的数量并不能提高CPU的利用率。下图描述的是随着CPU的数量增加，不同串行化比重的系统的加速比。

很显然，串行比重越大，增加CPU资源的效果越不明显。

性能提升

性能的提升可以从以下几个方面入手。

系统平台的资源利用率

一个程序对系统平台的资源利用率是指某一个设备繁忙且服务于此程序的时间占所有时间的比率。从物理学的角度讲类似于有用功的比率。简单的说就是：资源利用率=有效繁忙时间/总耗费时间。

也就说尽可能的让设备做有用的功，同时榨取其最大值。无用的循环可能会导致CPU 100%的使用率，但不一定是有效的工作。有效性通常难以衡量，通常只能以主观来评估，或者通过被优化的程序的行为来判断是否提高了有效性。

延迟

延迟描述的是完成任务所耗费的时间。延迟有时候也成为响应时间。如果有多个并行的操作，那么延迟取决于耗费时间最大的任务。

多处理

多处理是指在单一系统上同时执行多个进程或者多个程序的能力。多处理能力的好处是可以提高吞吐量。多处理可以有效利用多核CPU的资源。

多线程

多线程描述的是同一个地址空间内同时执行多个线程的过程。这些线程都有不同的执行路径和不同的栈结构。我们说的并发性更多的是指针对线程。

并发性

同时执行多个程序或者任务称之为并发。单程序内的多任务处理或者多程序间的多任务处理都认为是并发。

吞吐量

吞吐量衡量系统在单位之间内可以完成的工作总量。对于硬件系统而言，吞吐量是物理介质的上限。在没有达到物理介质之前，提高系统的吞吐量也可以大幅度改进性能。同时吞吐量也是衡量性能的一个指标。

瓶颈

程序运行过程中性能最差的地方。通常而言，串行的IO、磁盘IO、内存单元分配、网络IO等都可能造成瓶颈。某些使用太频繁的算法也有可能成为瓶颈。

可扩展性

这里的可扩展性主要是指程序或系统通过增加可使用的资源而增加性能的能力。

线程开销

假设引入的多线程都用于计算，那么性能一定会有很大的提升么？ 其实引入多线程以后也会引入更多的开销。

切换上下文

如果可运行的线程数大于CPU的内核数，那么OS会根据一定的调度算法，强行切换正在运行的线程，从而使其它线程能够使用CPU周期。

切换线程会导致上下文切换。线程的调度会导致CPU需要在操作系统和进程间花费更多的时间片段，这样真正执行应用程序的时间就减少了。另外上下文切换也会导致缓存的频繁进出，对于一个刚被切换的线程来说，可能由于高速缓冲中没有数据而变得更慢，从而导致更多的IO开销。

内存同步

不同线程间要进行数据同步，synchronized以及volatile提供的可见性都会导致缓存失效。线程栈之间的数据要和主存进行同步，这些同步有一些小小的开销。如果线程间同时要进行数据同步，那么这些同步的线程可能都会受阻。

阻塞

当发生锁竞争时，失败的线程会导致阻塞。通常阻塞的线程可能在JVM内部进行自旋等待，或者被操作系统挂起。自旋等待可能会导致更多的CPU切片浪费，而操作系统挂起则会导致更多的上下文切换。

了解了性能的提升的几个方面，也了解性能的开销后，应用程序就要根据实际的场景进行取舍和评估。没有一劳永逸的优化方案，不断的进行小范围改进和调整是提高性能的有效手段。当前一些大的架构调整也会导致较大的性能的提升。

简单的原则是在保证逻辑正确的情况小，找到性能瓶颈，小步改进和优化。

参考资料

• Amdahl's law: http://en.wikipedia.org/wiki/Amdahl%27s_law
• Gustafson's law: http://en.wikipedia.org/wiki/Gustafson%27s_law
• Sun-Ni law: http://en.wikipedia.org/wiki/Sun-Ni_law
• 多核系统中三种典型锁竞争的加速比分析 http://blog.csdn.net/drzhouweiming/article/details/1800319
• 阿姆达尔定律和Gustafson定律的等价性 http://book.51cto.com/art/201004/197506.htm

volatile

volatile只能强调数据的可见性，并不能保证原子操作和线程安全，因此volatile不是万能的。参考指令重排序

volatile最常见于下面两种场景。

a. 循环检测机制

volatile boolean done = false;


    while( ! done ){
        dosomething();
    }

b. 单例模型 （http://www.blogjava.net/xylz/archive/2009/12/18/306622.html）

synchronized/Lock

看起来Lock有更好的性能以及更灵活的控制，是否完全可以替换synchronized？

在锁的一些其它问题中说过，synchronized的性能随着JDK版本的升级会越来越高，而Lock优化的空间受限于CPU的性能，很有限。另外JDK内部的工具（线程转储）对synchronized是有一些支持的（方便发现死锁等），而对Lock是没有任何支持的。

也就说简单的逻辑使用synchronized完全没有问题，随着机器的性能的提高，这点开销是可以忽略的。而且从代码结构上讲是更简单的。简单就是美。

对于复杂的逻辑，如果涉及到读写锁、条件变量、更高的吞吐量以及更灵活、动态的用法，那么就可以考虑使用Lock。当然这里尤其需要注意Lock的正确用法。

Lock lock = 
lock.lock();
try{
    //do something
}finally{
    lock.unlock();
}

一定要将Lock的释放放入finally块中，否则一旦发生异常或者逻辑跳转，很有可能会导致锁没有释放，从而发生死锁。而且这种死锁是难以排查的。

如果需要synchronized无法做到的尝试锁机制，或者说担心发生死锁无法自恢复，那么使用tryLock()是一个比较明智的选择的。

Lock lock = 
if(lock.tryLock()){
    try{
        //do something
    }finally{
        lock.unlock();
    }
}

甚至可以使用获取锁一段时间内超时的机制Lock.tryLock(long,TimeUnit)。 锁的使用可以参考前面文章的描述和建议。

锁的边界

一个流行的错误是这样的。

看起来很合理的，对于一个线程安全的Map实现，要存取一个不重复的结果，先检测是否存在然后加入。 其实我们知道两个原子操作和在一起的指令序列不代表就是线程安全的。 割裂的多个原子操作放在一起在多线程的情况下就有可能发生错误。

实际上ConcurrentMap提供了putIfAbsent(K, V)的“原子操作”机制，这等价于下面的逻辑：

除了putIfAbsent还有replace(K, V)以及replace(K, V, V)两种机制来完成组合的操作。

提到Map，这里有一篇谈HashMap读写并发的问题。

构造函数启动线程

下面的实例是在构造函数中启动一个线程。

这里可能存在的陷阱是如果此类被继承，那么启动的线程可能无法正确读取子类的初始化操作。

因此一个简单的原则是，禁止在构造函数中启动线程，可以考虑但是提供一个方法来启动线程。如果非要这么做，最好将类设置为final，禁止继承。

丢失通知的问题

这篇文章里面提到过notify丢失通知的问题。

对于wait/notify/notifyAll以及await/singal/singalAll，如果不确定到底是否能够正确的收到消息，担心丢失通知，简单一点就是总是通知所有。

如果担心只收到一次消息，使用循环一直监听是不错的选择。

非常主用性能的系统，可能就需要区分到底是通知单个还是通知所有的挂起者。

线程数

并不是线程数越多越好，在下一篇文章里面会具体了解下性能和可伸缩性。 简单的说，线程数多少没有一个固定的结论，受限于CPU的内核数，IO的性能以及依赖的服务等等。因此选择一个合适的线程数有助于提高吞吐量。

对于CPU密集型应用，线程数和CPU的内核数一致有助于提高吞吐量，所有CPU都很繁忙，效率就很高。 对于IO密集型应用，线程数受限于IO的性能，某些时候单线程可能比多线程效率更高。但通常情况下适当提高线程数，有利于提高网络IO的效率，因为我们总是认为网络IO的效率比较低。

对于线程池而言，选择合适的线程数以及任务队列是提高线程池效率的手段。

对于线程池来说，如果任务总是有积压，那么可以适当提高corePoolSize大小；如果机器负载较低，那么可以适当提高maximumPoolSize的大小；任务队列不长的情况下减小keepAliveTime的时间有助于降低负载；另外任务队列的长度以及任务队列的拒绝策略也会对任务的处理有一些影响。

我承认写技术博客是一件特别辛苦和痛苦的事情。

写一篇技术博客需要大量的技术储备，同时自动亲自动手去实践，证实想表示的，发现要回避的问题，还需要将自己体验的过程记录下来，以便后来人能够避免类似的问题。

而这一切显然不是写一篇杂记或者转载一篇文章那么容易。

两年前写一个技术专题，断断续续写了两年，到今天依然没有完成。每次总是希望自己能够很认真、很努力的完成，甚至都有答应网友尽快完成的冲动。可是真正开始时才发现我的注意力明显没有当初那么集中了。

而我现在更喜欢更新那种Wiki式的技术判断，作为点滴的积累。没有压力，没有负担，随心随意。

也许需要更多的兴趣和毅力才能坚持下去，不管怎么说，今年还是希望能够有更多的技术文章出来，两年前的承诺也应该勇敢的兑现。

Ganglia安装指南 (基于CentOS 5.6)

安装依赖

rpm -ivh http://mirrors.sohu.com/centos/5/os/x86_64/CentOS/zlib-devel-1.2.3-3.x86_64.rpm
rpm -ivh http://mirrors.sohu.com/centos/5/os/x86_64/CentOS/freetype-devel-2.2.1-28.el5_5.1.x86_64.rpm
rpm -ivh http://mirrors.sohu.com/centos/5/os/x86_64/CentOS/libart_lgpl-devel-2.3.17-4.x86_64.rpm
rpm -ivh http://mirrors.sohu.com/centos/5/os/x86_64/CentOS/libpng-devel-1.2.10-7.1.el5_5.3.x86_64.rpm

如果上述安装失败，可能需要安装以下库依赖

yum install zlib freetype libart_lgpl libpng

安装rrdtools

http://oss.oetiker.ch/rrdtool/pub/rrdtool-1.2.27.tar.gz
tar zxvf rrdtool-1.2.27.tar
cd rrdtool-1.2.27
./configure --prefix=/usr/local/rrdtool
make
make install

执行下命令，看是否安装成功

/usr/local/rrdtool/bin/rrdtool

安装expat依赖

http://downloads.sourceforge.net/project/expat/expat/2.0.1/expat-2.0.1.tar.gz?use_mirror=cdnetworks-kr-2
tar zxvf expat-2.0.1.tar.gz
./configure --prefix=/usr/local/expat
make
make install

对于64位操作系统，需要手动的拷贝下动态链接库到lib64下

mkdir /usr/local/expat/lib64
cp -a /usr/local/expat/lib/* /usr/local/expat/lib64/

安装apr以及apr-util

http://labs.renren.com/apache-mirror/apr/apr-1.4.5.tar.gz
tar xvjf apr-1.3.2.tar.bz2
./configure --prefix=/usr/local/apr
make
make install

http://labs.renren.com/apache-mirror/apr/apr-util-1.3.12.tar.gz
tar xvjf apr-util-1.3.2.tar.bz2
./configure --with-apr=/usr/local/apr --with-expat=/usr/local/expat
make
make install

同样64位机器需要拷贝动态链接库

/bin/cp -f /usr/local/apr/include/apr-1/* /usr/local/apr/include/
mkdir -p /usr/local/apr/lib64
/bin/cp -a -f /usr/local/apr/lib/* /usr/local/apr/lib64/

安装confuse

http://download.savannah.gnu.org/releases/confuse/confuse-2.7.tar.gz
tar zxvf confuse-2.6.tar.gz
./configure CFLAGS=-fPIC --disable-nls --prefix=/usr/local/confuse
make
make install

拷贝动态链接库

mkdir -p /usr/local/confuse/lib64
/bin/cp -a -f /usr/local/confuse/lib/* /usr/local/confuse/lib64/

安装ganglia

现在才是安装ganglia的开始，如果提示需要pcre的话，安装下 yum install pcre 下载ganglia-3.2.0，解压，安装

./configure --prefix=/usr/local/ganglia --with-librrd=/usr/local/rrdtool --with-libapr=/usr/local/apr --with-libexpat=/usr/local/expat \
--with-libconfuse=/usr/local/confuse --with-gmetad --enable-gexec --enable-status --sysconfdir=/etc/ganglia
make
make install

服务端配置

创建rrdtool数据目录，看$ganglia-3.2.0/web/conf.php里面的gmetad_root变量，并根据apache的运行用户创建权限，例如apache运行于apache用户上 。

mkdir -p /var/lib/ganglia/rrds
mkdir -p /var/lib/ganglia/dwoo
chown -R apache;apache /var/lib/ganglia

配置一个数据源，修改/etc/ganglia/gmetad.conf文件，同时将运行用户设置为rrdtool的目录权限用户，例如apache用户

data_source "suc" localhost
setuid_username "apache"

其中suc是数据源的名称，客户端分组会依赖此名称，后面会提到。 添加自启动脚本

/bin/cp -f gmetad/gmetad.init /etc/init.d/gmetad
/bin/cp -f /usr/local/ganglia/sbin/gmetad /usr/sbin/gmetad
chkconfig -add gmetad

启动gmetad服务

service gmetad start

看见Starting GANGLIA gmetad: [ OK ]就代表运行正常了。

客户端配置（gmond节点）

本机安装如下：

/bin/cp -f gmond/gmond.init /etc/init.d/gmond
/bin/cp -f /usr/local/ganglia/sbin/gmond/usr/sbin/gmond
chkconfig -add gmond
gmond --default_config > /etc/ganglia/gmond.conf

对于生成的默认配置文件需要做适当的修改

cluster {
name="suc"
owner="apache"
latlong="unspecified"
url="unspecified"
}

其中name是将要在服务端进行的分组，是服务端的数据源。接下来开启服务

service gmond start

看见Starting GANGLIA gmetad: [ OK ]代表启动成功。如果有失败，可以讲gmond.conf中的debug有0改为100，看更多的日志，然后进行排查。

globals {
daemonize = yes
setuid = yes
user = nobody
debug_level = 100
}

非本机客户端配置需要安装服务端安装一样进行配置，运行，非常麻烦，这里使用本机安装好的文件进行安装。 使用下面的脚本进行安装deploy-ganglia.sh

i=$1
scp /usr/sbin/gmond $i:/usr/sbin/gmond
ssh $i mkdir -p /etc/ganglia/
ssh $i mkdir -p /usr/local/ganglia/lib64
ssh $i mkdir -p /usr/local/expat/lib
scp /etc/ganglia/gmond.conf $i:/etc/ganglia/
scp /etc/init.d/gmond $i:/etc/init.d/
scp -r /usr/local/ganglia/lib64/* $i:/usr/local/ganglia/lib64/
scp /usr/local/expat/lib/libexpat.so.1 $i:/usr/local/expat/lib/libexpat.so.1
scp /usr/lib64/libapr-1.so.0 $i:/usr/lib64/

实际上就是将本机安装好(编译好)的动态链接库拷贝到其它机器上，使用如下命令拷贝即可

sh deploy-ganglia.sh 10.1.11.2

服务端的WEB配置

PHP程序需要依赖Apache来运行，因此需要安装如下依赖

yum install php-common php-cli php php-gd httpd

安装web程序，这里假定apache的root路径在/var/www/html下面。

mkdir /var/www/html/ganglia
cp -a -f ganglia-3.2.0/web/* /var/www/html/ganglia

禁用SELinux setenforce 0 修改rrdtool的路径，文件/var/www/html/ganglia/conf.php中的RRDTOOL

define("RRDTOOL", "/usr/local/rrdtool/bin/rrdtool");

重启httpd服务器即可看到效果 service httpd restart



例如在Future接口中有如下一个API：

在前面的章节中描述了Future类的具体实现原理。这里不再讨论，但是比较好奇的抛出的三个异常。

这里有一篇文章（Java 理论与实践: 处理 InterruptedException）描述了InterruptedException的来源和处理方式。简单的说就是线程在执行的过程中被自己或者别人中断了。这时候为了响应中断就需要处理当前的异常。

对于java.lang.Thread而言，InterruptedException也是一个很诡异的问题。

中断一个线程Thread.interrupt()时会触发下面一种情况：

如果线程在调用 Object 类的 wait()、wait(long) 或 wait(long, int) 方法，或者该类的 join()、join(long)、join(long, int)、sleep(long) 或 sleep(long, int) 方法过程中受阻，则其中断状态将被清除，它还将收到一个 InterruptedException。

检测一个线程的中断状态描述是这样的Thread.interrupted()：

测试当前线程是否已经中断。线程的中断状态 由该方法清除。换句话说，如果连续两次调用该方法，则第二次调用将返回 false（在第一次调用已清除了其中断状态之后，且第二次调用检验完中断状态前，当前线程再次中断的情况除外）。 

也就是说如果检测到一个线程已经被中断了，那么线程的使用方（挂起、等待或者正在执行）都将应该得到一个中断异常，同时将会清除异常中断状态。

上面获取任务结果的方法实现中，将在获取锁的过程中得到一个中断异常。代码java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(int, long)描述了这种情况：

这里在获取锁的时候检测线程中断情况，如果被中断则清除中断位，同时抛出一个中断异常。为什么如此做？因为我们的线程在线程池中是被重复执行的，所以一旦线程被中断后并不会退出线程，而是设置中断位，等候任务队列自己处理线程，从而达到线程被重复利用的目的。有兴趣的可以参考代码java.util.concurrent.ThreadPoolExecutor.Worker.runTask(Runnable)。这里在关闭线程池时就会导致中断所有线程。

除了InterruptedException 异常我们还发现了一个全新的异常java.util.concurrent.TimeoutException，此异常是用来描述任务执行时间超过了期望等待时间，也许是一直没有获取到锁，也许是还没有执行完成。

在innerGet代码片段中我们看到，如果线程在指定的时间无法获取到锁，那么就会得到一个超时异常。这个很好理解，比如如果执行一个非常耗时的网络任务，我们不希望任务一直等待从而占用大量的资源，可能在一定时间后就会希望取消此操作。此时超时异常很好的描述了这种需求。

与此同时，如果取消了一个任务，那么再次从任务中获取执行结果，那么将会得到一个任务被取消的异常java.util.concurrent.CancellationException。

除了上述异常外，还将得到一个java.util.concurrent.ExecutionException异常，

这是因为我们的提交的任务java.util.concurrent.Callable在call()方法中允许抛出任何异常，另外常规的线程执行也可能抛出一个RuntimeException，所以这里简单包装了下所有异常，当作执行过程中发生的异常ExecutionException抛出。

以上就是整个异常体系，所有并发操作的异常都可以归结于上述几类。

很多情况下处理时间长度都是用java.util.concurrent.TimeUnit，这是一个枚举类型，用来描述时间长度。其中内置了一些长度的单位。其中包括纳秒、微秒、毫秒、秒、分、时、天。例如超时操作5秒，可以使用

Future.get(5,TimeUnit.SECONDS) 或者 Future.get(5000L,TimeUnit.MILLISECONDS)

当然一种单位的时间转换成另一种单位的时间也是非常方便的。另外还有线程的sleep/join以及对象的wait操作的便捷操作。

你还在为频繁部署服务器而烦恼么？

亲，试试jrebel吧。更多jrebel的介绍参考这里http://www.zeroturnaround.com/jrebel/。

啊？免费版只能使用30天？花钱？十个人的团队使用一年的企业版License是2891$！你没看错，是真真正正的美帝国的钱！

好吧，我等穷人使用不起，只好“自己动手/丰衣足食”。

这里提供了一个完整功能的企业版，免费大甩送了，有木有!!!

怎么使用，最简单方式,在resin的启动文件，例如httpd.sh中增加：

Resin 3.1+版本：

exec $JAVA_EXE -javaagent:/opt/apps/resin/jrebel4.0-crack.jar -jar ${RESIN_HOME}/lib/resin.jar $*

Resin 3.0-版本：

args=”-J-javaagent:/opt/apps/resin/jrebel4.0-crack.jar“

Tomcat？Jetty? Jboss? WebLogic? WebSphere? Maven? Eclipse? And More?

OK，参考这里文档吧：http://www.zeroturnaround.com/reference-manual/

亲，不要钱的，试试吧！

有木有更简单，更NB的热部署秘籍啊？

有的，亲！

如果你的Linux x86 (x86_64位目前没有)的glibc是2.4+版本，试试dcevm吧！Windows 32/64位同样有相应的版本啊！