配置需求说明

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),配置框架会自动在该行后插入配置代码. 这种方式的主要的问题是用户理解困难,项目组支持的工作量大;不过这也是没有办法的办法了.
   

总结

JSRB定位与想要解决的问题

无状态vs有状态,远程调用的选择.

SERVICE的粒度问题

其它

1. 本文的一些思想来源于MidWay(midway.sourceforge.net)和个人的项目经验,仅为一家之言.
2. 大型项目(企业级)和小项目(部门级)的区别主要就在于,大项目在各个阶段都要将非功能性的要求(性能,容错,恢复,分布式,响应时间,事务等等)放在设计/实现/测试首要考虑的位置,而小项目则几乎无需考虑这样的问题.
3. 本文和JSRB主要集中在真正的中间层( Service/Object Request Broker/EJB Container).
   

JSRB SERVICE 特性/访问方式

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

尝试Lucene以及放弃原因：

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

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

1 HTML页面、Web应用、ASP 程序源文件全部采用 UTF-8 编码。
在文件头部加入行<%@ LANGUAGE=JScript CODEPAGE=65001%>

2 SQL Server 2000 数据库：
    1 数据库字符串字段采用 NVARCHAR/NTEXT/NCHAR Unicode 字符类型。
    2 数据库操作SQL 中，字符串全部加 N 前缀： SELECT * FROM TABLE WHERE FIELD LIKE N'中文%'

3 ASP 程序如果要访问文件，需要用如下代码打开 UTF-16 格式文件：
FileSystemObject.OpenTextFile(file,1,false,-1);
保证在不同平台下，相同文件都能够正确读取。

4 ASP 源文件中，不包含任何语言相关字符串，如标题、错误消息。这些消息统一保存到某个文件inc_l10n.asp中。另外，提供一个 inc_strutil.asp 程序，辅助格式化字符串。
这样，要更换语言版本，只要更新的 inc_l10n.asp 即可。

inc_l10n.asp
<%
var l10n_title = "ASP Application Title";
var l10n_about= "About ASP Application";
var l10n_dict_homename = "HOME NAME";
%>

inc_strutil.asp:
<%
//Replace a substring in a String
//
function replaceAll(data, from, to) {
    var buf = "";
    var pos = -1;
    var i = 0;
    while ((pos = data.indexOf(from, i)) != -1) {
        buf = buf + (data.substring(i, pos))+ to;
        i = pos + from.length;
    }
    buf = buf + data.substring(i);
    return buf;
}

//return the substitution result from Resource String
//Invoke examples: getString("Substitution Example: $1 $2","111","222")
//Invoke Result: "Substitution Example: 111 222"
function getString()
{
    if ( arguments.length == 0 )
        return "";
    if ( arguments.length == 1 )
        return ""+arguments[0];
    var rawStr = arguments[0];
    var i = 0;
    for(i=1;i<arguments.length;i++){
        rawStr = replaceAll(rawStr,"$"+i,arguments[i]);   
    }
    return rawStr;
}
%>

• 业务框架发展策略
• 业务框架支持代码复用
• 业务框架支持CMM实施

变的是概念，不变的是产品
IBM 的 MQ Series 的定位从老早的 Link/Queue ，变为 MOM ，再变为 EAI ，再变为 SOA 的基础架构。MQ Series 产品的结构始终不变，但 IBM 将它用不同的概念包装起来，推向市场；客户为概念付费，而 IBM 在收获真金白银。

变的是皮毛，不变的是基础
变的是排列组合，不变的是基本原理
仔细考究这些概念，就会发现，概念其实只不过是对角色、数据、处理和它们之间的相互关系，将其固定化和明确化，再起个新名词。很多现在热炒的新概念，在70年代的主机上可以找到原型；代码不管是OOP 还是 AOP ，最终还是要翻译成机器码，由CPU 执行的。
别被新概念给骗了，我们现在用的计算机的结构，从1950's 诺伊曼提出开始，就没有什么新变化。在可预见的将来，除非人工智能或量子计算机有什么新突破，我们还是要继续跟诺伊曼体系打交道。

变的是银弹，不变的是失望(?)
巨型厂商所推的概念，更多程度上是为了营销所作的吹嘘。从用户角度来看，只要开发速度足够快，运行稳定，后续支持维护升级能够跟上；到底采用什么技术，是无所谓的事情。而技术或框架之间的差别，其实也没有它们的简称之间的差别那么大。

正则表达式说明

---

目录

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增加了对 超大字符集的支持，只要设置字体正确，就可以显示和编辑超大字符集。

笨笨所知的测试大致分类

单元测试/Unit test
基于代码中类或函数一级的测试

用例测试/Use case test.
基于一个完整业务用例的测试，可以不包括用户业务系统环境的完整操作流程。
如，银行网银系统的转账测试可以认为是一个完整业务用例测试，但是不必要要求测试用例先执行登录过程，再进行转账业务代码的测试。

集成测试/Integration test
由业务人员主导，业务系统作为一个完整黑盒，测试系统功能和性能。

用户接受测试/User Accept test
集成测试通过后，用户基于生产系统剥离的实际数据，再一次对业务系统执行测试；如果集成测试不充分，可以再一次有机会暴露系统的缺陷。

项目实施过程与测试

从项目的实施过程来说，单元测试是程序员自测，算在开发阶段，集成测试和用户接受测试所占用时间能够达到项目代码开发阶段的一倍到两倍，大型项目的测试阶段可能还要长。
而用例级测试目前很少作为一个正式的阶段在项目实施过程中存在，或由程序员自行自测，或合并到集成测试过程中。

对于大型业务系统，集成测试和用户测试所花费的主要工作量如下，可能不全。
1 数据准备，测试人员调配准备。
2 测试过程中，测试人员要找到哪些测试数据还能用，再手工操作系统界面，执行测试过程。对于大型业务系统来说，可用测试数据是随着测试进展不断变化的，很有可能某个用户数据刚刚状态正常，现在就欠费了。要想找到合适的数据来测试系统，这是个费劲且混乱的过程。
3 集成回归测试，业务系统如果有升级或改动，需要将所有交易重新测试一遍，以防止变更给原有代码引入缺陷。

用例测试
用例测试关注业务。

用例测试集中在业务服务这一层，业务服务直接对应了业务用例。
用例测试注重业务服务运行环境的模拟和重现，从而支持业务服务层的自动测试。

用例测试的价值
1 减少集成测试的时间和成本，降低集成测试发现缺陷数，从而降低项目总缺陷修复代价。
 用例测试缺陷修复代价远低于集成测试的缺陷修复代价；用例测试发现大部分缺陷后，集成测试就相对轻松了。
2 可回归的用例测试支持快速代码重构。
3 ...

单元测试无法覆盖用例测试
业务代码运行需要底层资源如数据库或其它业务系统配合，单元测试工具缺乏提供业务服务运行所需环境的模拟，从Junit系列单元测试工具来说，它还是主要从技术角度考虑，从业务角度的考虑如：
底层资源（数据库，JMS）模拟
依赖服务模拟
服务访问模拟
自动检测、重放和比对服务运行时的输入输出参数、资源、依赖服务。
服务接口变动波及分析

代码重构的成本
代码重构需要付出代价。集成测试费时费力，但用户不可能因为程序员说“我保证代码重构不会改变系统功能”，就不对变动后代码进行测试。
用例回归测试支持可以以较小代价支持代码重构，因为它可在业务服务级自动对功能进行验证，集成测试工作能够相应的减少。

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。

对于分布式应用，有可能需要自行编写元数据更新的分布式事务管理器，自行实现元数据更新的两阶段提交过程。如果想偷懒，也可以考虑用JCA自行实现Resource Manager，借用应用服务器的Transaction Manager。

基本代码执行
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。