配置需求说明

1. 复制文件到某处
2. 创建/append 某个 properties/txt 文本文件
3. 修改脚本文件,插入一段文本到脚本文件某处
4. 通过JMX/JNDI连接到远程应用服务器, 用Java code修改应用服务器的配置.

需求分析

1. 配置过程需要有类似于事务的机制,以保证多处改动的一致性.
2. 各种配置过程之间有许多相同之处,为减少重复,可以考虑引入公共配置片断文件.
3. 由于配置过程相对固定, ANT BUILD XML文件的多个target以及依赖关系检查就不需要了,但是需要更加灵活的条件判断机制来控制单个配置动作和变量赋值.

实现简介

1. Action.performAction(): 实现正常配置动作,如果失败则返回错误码.
2. Action.performCompensation(): 实现回滚动作,负责将配置对象(如文件内容)回滚到修改前的状态.
3. Action.performComplete(): 实现正常配置完成动作, 负责释放配置过程占用的临时资源.
   

其它特性:脚本文件自动分析和插入配置行

1. 对脚本进行语法分析,找出脚本的Java启动行(或Windows Service设置行),进而找出可用的shell变量和插入位置. 期望这种方式能够解决大多数用户自定义脚本.
   
2. 对于复杂或分析条件不充分的脚本(如变量位于别的文件), 用户需要在合适位置插入一行有指定格式和参数的注释行(称之为anchor),配置框架会自动在该行后插入配置代码. 这种方式的主要的问题是用户理解困难,项目组支持的工作量大;不过这也是没有办法的办法了.
   

总结

最近在项目中面临中文全文检索的需求，关键需求如下：

尝试Lucene以及放弃原因：

自行实现中文全文检索原理以及方法：

目前实现的一些局限和优势：

正则表达式说明

---

目录

1. 字符
2. 逻辑操作符
3. 向后引用
4. 边界元字符
5. 重复指示符
6. 字符子集
7. 预定义子集（元字符）
8. 扩展子集（元字符）
9. 扩展中文子集（元字符）
10. POSIX字符子集（只适用于ASCII）
11. Unicode块和分类
    

1. 特殊字符
2. 自定义替换表
   

匹配模式

字符子集

1. 转义符\x
2. 成组符 [...]
3. 区间符 a-z
4. 联合符 [a-e][i-u]
5. 交集符 [a-z&&[aeiou]]

行结束符

• 一个换行符('\n')。
• 一个回车符加上一个换行符("\r\n")。
• 一个单独的回车符('\r')。
• 代表下一行的字符('\u0085')。
• 行分隔符('\u2028')，Unicode中被定义。
• 一个分段符('\u2029)，Unicode中被定义。

分组和引用

1. ((A)(B(C)))
2. (A)
3. (B(C))
4. (C)

Unicode支持

与Perl 5正则表达式语法对比

正则表达式参考

字符

逻辑操作符

向后引用

边界元字符

重复指示符

字符子集

预定义子集（元字符）

扩展子集（元字符）

扩展中文子集（元字符）

POSIX字符子集（只适用于ASCII）

Unicode块和分类

替换表达式

垂直扩展，简单的说，是当单一系统硬件升级扩展时，如增加CPU，内存，应用程序能够随之线性提高业务处理能力。
多线程是服务端 Java 应用的标准处理方式，其优点不用赘述。本文要讨论的是，如何在设计阶段降低多线程之间的竞争性同步开销。

假设一个Web应用，需要为当前用户维护在线用户信息。此用户信息列表会放在 Application 范围的一个 Map 中，那么我们增加或删除一个在线用户的操作会是这样：。
Map clientMap = ...// from Application Context
synchronized(clientMap){
 clientMap.put(clientId,clientObject);
}
这是一个典型的全局同步代码，当并发线程增加时，这部分代码就有可能会存在潜在垂直扩展瓶颈。

最简单解决办法：用 ConcurrentHashMap。
ConcurrentHashMap的多线程下的表现要比HashMap好的多，可以做到随着线程数增长性能基本保持稳定。
参见：http://www-128.ibm.com/developerworks/cn/java/j-jtp07233/index.html
对 ConcurrentHashMap 的分析，参见：http://www-128.ibm.com/developerworks/cn/java/j-jtp08223/index.html

在 ConcurrentMap/ConcurrentLinkedQueue 不能帮助我们的情况下，我们需要明确设计以避免全局竞争。
基本原则是：
1 预分配，降低争用出现的频率。
2 降低锁的粒度，将全局竞争变为局部竞争。

预分配策略示例：
对于一在线交易处理系统，需要为每个交易生成交易流水号，假设有多台交易服务器按照集群方式配置，同时提供服务。那么需要在交易服务器之间进行同步，以保证交易流水号的正常增长。
一种处理方式为：在数据库中保存当前交易流水号的最高值，每台机器一次预分配1000流水，内部采用线程同步进行分配，用完再从数据库分配。这里数据库充当了全局存储和全局同步工具，如果每来一条交易，就访问一次数据库，考虑到数据库同步和事务的负担，这里会成为严重的性能瓶颈。

降低锁粒度策略示例：
1 ConcurrentHashMap 本身就是个很好的模范。它采用32颗锁，来代替普通 HashMap 的单颗对象锁。
2 对于数据库中并发大的表，可以考虑将表级锁改为行级锁，提高并发性。

暂时想不起来示例，有空再补

Unicode 与超大字符集
国标 GB18030 规定了4字节扩展部分，这部分区域目前在 Unicode 规范中作为CJK Ext B区存在，即常说的中文超大字符集。这部分区域编码为 \U20000 - \U2A6D6。

UTF-16与Java String/Character 对象
一个完整的 Unicode 字符叫 代码点/CodePoint，而一个 Java char 叫 代码单元 code unit。
String 对象以UTF-16保存 Unicode 字符，需要用2个字符表示一个 超大字符集的汉字，这这种表示方式称之为 Surrogate，第一个字符叫 Surrogate High，第二个就是 Surrogate Low。

判断一个char是否是 Surrogate 区的字符，用 Character的 isHighSurrogate()/isLowSurrogate()方法。
从两个Surrogate High/Low 字符，返回一个完整的 Unicode CodePoint 用 Character.toCodePoint()/codePointAt()方法。

一个 Code Point ，可能需要一个也可能需要两个char表示，因此不能直接使用 CharSequence.length()方法直接返回一个字符串到底有多少个汉字，而需要用String.codePointCount()/Character.codePointCount()。

要定位字符串中的第N个字符，不能直接将 N 作为偏移量，而需要从字符串头部依次遍历得到，需要用String/Character.offsetByCodePoints() 方法。

从字符串的当前字符，找到上一个字符，也不能直接用offset -- 实现，而需要用 String.codePointBefore()/Character.codePointBefore()，或用 String/Character.offsetByCodePoints()

从当前字符，找下一个字符，不能直接用 offset ++ 实现，需要判断当前 CodePoint 的长度后，再计算得到，或用 String/Character.offsetByCodePoints() 。

Swing 对 超大字符集的支持
JTextPane增加了对 超大字符集的支持，只要设置字体正确，就可以显示和编辑超大字符集。

JVM Thread DUMP 基本功
Windows 下用Ctrl-Break,Unix 下用 kill -3 <pid> 的命令让JVM输出 thread dump。
每隔几秒 thread dump 一次，多做几次，分析比较。

Thread Dump分析的一些经验
1 找出这几次Thread dump 文件中，有哪些 Java Thread 处于长时间等待状态，很有可能就是问题之所在。
2 如果Java 线程等在某些不可能出错的地方，如 java.lang.XXX/java.util.XXX对象的某个方法，则很有可能是因为出现了 OutOfMemoryError 异常，原因不外乎是JVM 堆内存过小或出现内存泄漏。
3 对于死锁，最直接的表现就是至少两个线程长时间等待相互持有的对象（每个线程所持有的对象和它当前等待的对象都可以从 dump 中看到）。
4 对于死循环，要辅助CPU占用率确定；如果发现CPU至少一颗使用率为100%，并且有线程长时间位于用户代码处，则很有可能是死循环引起。

多线程缺陷排查
对于Java死锁问题很少出现，多线程访问变量时冲突很常见。
一般出在多线程共享同一对象实例如全局Map，Servlet,Interceptor，或如多线程同时访问某个静态方法，而此静态方法不巧又访问另一个静态变量。
这类问题自测发现不了，在并发压力测试时才能发现。如果代码的入口检查做得好，多半会抛出一些莫名其妙的异常；要不然就会出现正常运行但数据库记录不对的情况。
对这种问题，并无多好的办法解决，主要还是靠看异常堆栈和静态代码分析来解决。


内存泄漏排查
一般用商用辅助工具排查，但有可能出现在JVM heap dump 模式下，运行极度缓慢的情况。
笨笨曾经用过一个非常简单的工具，效果不错，它可以做到在不影响jvm 执行速度的情况下，做heap dump，然后对dump出的文件进行排序，检查即可。

heapprofile(http://www.virtualmachine.de/)

EJB 运行时所享受的 J2EE 基础服务

1 参与AppServer 提供分布式事务管理(JTA,JTS)。
2 AppServer 提供高性能通讯框架(基于RMI 或 IIOP实现)和大并发处理。
 1) AppServer 如 WebLogic/WebSphere 替换了 Sun 标准 RMI 实现（基于著名的多线程阻塞IO），国内的 Apusic 4 则基于纯 NIO 的 IIOP通讯协议实现EJB 远程通讯。
 2) AppServer 提供 EJB 实例池、请求队列、执行线程池等等服务。

3 AppServer 提供透明 EJB 集群管理（负载均衡、故障恢复），保证应用的处理能力能够水平扩展。
4 J2EE 安全体系
5 AppServer 特有的附加增值服务
 1) 如 WebLogic WTC EJB，可实现从TUXEDO Service(C语言) 高性能访问 EJB。

大型项目所关注的重点

对于大型项目如全国集中这一级别而言，它所关注的重点风险反而是系统的性能、吞吐量、稳定性、高可用性这样的一些基本属性，这里并非说具体的业务功能就不重要；而是与上述的基本属性相比，业务功能可以说是相对的不重要。
基本属性如果有某一项没有达到，直接后果就是项目失败，或者运行时存在高风险。
业务功能则主要是堆时间、堆人、堆代码、堆测试人员的问题，如果实在来不及了，那就放到第二期去做好了，不影响主旋律么。

对于大型项目而言，采用新技术的关注点主要是：
1 能否满足基本质量属性，无重大运行时风险。
比如说，数据访问层，从性能和稳定性角度而言，还算直接采用 JDBC 编码合适，最多采用SQL映射型JDO。对于带缓冲的JDO实现则不宜采用，会带来水平扩展和稳定性风险。

2 项目组相关人员是否有此技术的经验，最好不要付出学习成本，避免因不熟悉所带来的风险。

EJB 和 IoC 框架如 Spring 的定位比较

Spring IoC/Context/AOP 可以认为是一个代码组织(Assembler)框架，关注代码如何组织和去耦。

EJB 则是运行结构，关注我们的应用如何运行，如何做集群，系统计算资源如何分配等等。
EJB 3 的改进主要还是从代码组织角度做出的，对于 EJB 运行时架构并没有多少变化（如果说错了，还请指正）；BEA 还有过将 EJB 3的代码翻译为 EJB 2.1 运行时架构的考虑（参见 BEA 的关于 EJB 3 的一篇文章http://www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb_p.html）。

从上述角度来看，EJB 和 Spring 是从不同的角度看待应用，我们完全可以做到用 Spring 组织代码实现EJB。

With or Without EJB?
从上述讨论可以看出，用Spring还是用EJB并不是个问题，最终还是看用户的实际需求而定。小Web项目多半不关注性能、并发、集群等等属性，出于开发过程简单和学习成本的考虑，完全可以不用EJB；而大型项目可能还是得用EJB。

基本代码执行
Java与C在 1:3-1:5左右，在Intel平台上用JDK1.4测得。
JNI不快，一次基本JNI调用差不多等于一次Java方法调用（未考虑大数据量传输）

数据库访问
JDBC与数据库本地接口差距较大，差不多在1到2个数量级左右，或更多。可以认为在1:10 - 1:50之间

socket网络传输
Java要分普通多线程和NIO方式
多线程方式，并发受限，一般不会超过150-200个并发，再多性能不会增加。这种方式下，网络传输性能与C差距可以认为在1个数量级左右，即1:10-1:30。
NIO方式，并发不错，能够支持到几千个并发，性能差距小些，可以做到在1:3 -- 1:5 左右。
C 通过select/poll/epoll技术，并发10000没有多少问题，并且通过Zero-Copy技术，可以避开Java 所无法避免缓冲区复制(Java->C缓冲区复制)的问题。

总的来看，Java与C在普通多层Web应用方面，差距可以认为在1个数量级左右，关键应用如TP Monitor目前还无法使用Java。