摘要: 以下以 IE 代替 Internet Explorer，以 MF 代替 Mozzila Firefox
1. document.form.item 问题
(1)现有问题：
现有代码中存在许多 document.formName.item("itemName") 这样的语...
阅读全文
OSCache是当前运用最广的缓存方案。其主被用的最广泛功能是缓存页面，这里主要是用其缓存文件对象。
运用OScache的步骤：
1.取得oscache.jar 文件放到 /WEB-INF/lib 或相应类库目录 目录中。
2.oscache.jar依赖commons-collections.jar包。如果你的jdk版本为1.3,
建议在lib中加入Apache Common Lib 的commons-collections.jar包。
如jdk是1.4以上则不必要。
3.src根目录或发布环境的/WEB-INF/classes 目录下放入oscache.properties。
cache.memory
值为true 或 false ，默认为在内存中作缓存，
如设置为false，那cache只能缓存到数据库或硬盘中，那cache还有什么意义：）
cache.capacity
缓存元素个数
cache.persistence.class
持久化缓存类，如此类打开，则必须设置cache.path信息
cache.cluster 相关
为集群设置信息。
如cache.cluster.multicast.ip为广播IP地址
cache.cluster.properties为集群属性
cache.path
硬盘持久化时存放文件的目录。如果目录不存在OSCache会自动创建。
Windows系统：c:\\myapp\\cache。其它：/opt/myapp/cache
cache.persistence.overflow.only*
是否只有当指定的内存缓存已经满时才进行持久化。推荐使用true，flase是为向后兼容。
cache.unlimited.disk
硬盘缓存是否有限制。缺省为cache.capacity指定的值
运用：
com.opensymphony.oscache.general.GeneralCacheAdministrator
GeneralCacheAdministrator主要对实现持久化对象的保存以及取出的相关的操作。
Object getFromCache（String key） //根据key获取缓存对象
Object getFromCache（String key , int refreshInterval）//refreshInterval时间内，根据key获取缓存对象
void putInCache(String key ,Object obj) //保存被缓存对象
void flushAll() //删除所有被缓存的对象
void flushAll(Date date) //在指定的时间去删除所有被缓存的对象
void cancelUpdate(String key) //取消未确定的更新
Java代码
1 package com.iflytek;
2
3 import java.io.BufferedInputStream;
4 import java.io.BufferedOutputStream;
5 import java.io.File;
6 import java.io.FileInputStream;
7 import java.io.IOException;
8 import java.text.SimpleDateFormat;
9 import java.util.Date;
10
11 import javax.servlet.ServletException;
12 import javax.servlet.http.HttpServlet;
13 import javax.servlet.http.HttpServletRequest;
14 import javax.servlet.http.HttpServletResponse;
15 import javax.servlet.http.HttpSession;
16
17 import com.opensymphony.oscache.base.NeedsRefreshException;
18 import com.opensymphony.oscache.general.GeneralCacheAdministrator;
19
20
21 public class DisplayChart extends HttpServlet {
22
23 /**
24 * Default constructor.
25 */
26 public DisplayChart() {
27 super();
28 }
29
30 /**
31 * Init method.
32 *
33 * @throws ServletException never.
34 */
35 public void init() throws ServletException {
36 return;
37 }
38
39
40 public static GeneralCacheAdministrator cacheAdmin = new GeneralCacheAdministrator();
41 public void service(HttpServletRequest request,
42 HttpServletResponse response)
43 throws ServletException, IOException {
44
45 String path = getServletContext().getRealPath("/");
46 File file = null;
47 SimpleDateFormat sdf= new SimpleDateFormat("hh-mm-ss");
48 try {
49 file = (File)cacheAdmin.getFromCache(sdf.format(new Date()));
50 System.out.println("来自缓存!"+ sdf.format(new Date()));
51 } catch (NeedsRefreshException e) {
52 file = new File(path+"xmls\\Pipe11.xml");
53 cacheAdmin.putInCache(sdf.format(new Date()), file);
54 System.out.println("--缓存没有!"+sdf.format(new Date()));
55 }
56 sendResponse(file,response);
57 return;
58 }
59 /**
60 * 把文件用响应流写出
61 * @param file
62 * @param response
63 * @throws IOException
64 */
65 public void sendResponse(File file,HttpServletResponse response) throws IOException{
66 BufferedInputStream bis = new BufferedInputStream(new FileInputStream(file));
67 BufferedOutputStream bos = new BufferedOutputStream(response.getOutputStream());
68 byte[] input = new byte[1024];
69 boolean eof = false;
70 while (!eof) {
71 int length = bis.read(input);
72 if (length == -1) {
73 eof = true;
74 }
75 else {
76 bos.write(input, 0, length);
77 }
78 }
79 bos.flush();
80 bis.close();
81 bos.close();
82 }
83
84 }
85
首先了解一下Singleton模式通常的两种表现形式：
第一种形式：
public class Singleton {
private Singleton(){}
//在自己内部定义自己一个实例，是不是很奇怪？
//注意这是private 只供内部调用
private static Singleton instance = new Singleton();
//这里提供了一个供外部访问本class的静态方法，可以直接访问
public static Singleton getInstance() {
return instance;
}
}
第二种形式：
public class Singleton {
private static Singleton instance = null;
public static synchronized Singleton getInstance() {
//这个方法比上面有所改进，不用每次都进行生成对象，只是第一次
//使用时生成实例，提高了效率！
if (instance==null) instance＝new Singleton();
return instance;
}
}
使用Singleton.getInstance()可以访问单态类。
上面第二中形式就是lazy initialization，也就是说第一次调用时初始Singleton，以后就不用再生成了。
注意到lazy initialization形式中的synchronized，这个synchronized很重要，如果没有synchronized，那么使用getInstance()是有可能得到多个Singleton实例。
那么为什么只有使用synchronized关键字才可以达到单态的目的呢？synchronized到底有什么含义呢？
synchronized 关键字，它包括两种用法：synchronized 方法和 synchronized 块。
1. synchronized 方法：通过在方法声明中加入 synchronized关键字来声明 synchronized 方法。如：
public synchronized void accessVal(int newVal);
synchronized 方法控制对类成员变量的访问：
每个类实例对应一把锁，每个 synchronized 方法都必须获得调用该方法的类实例的锁方能执行，否则所属线程阻塞，方法一旦执行，就独占该锁，直到从该方法返回时才将锁释放，此后被阻塞的线程方能获得该锁，重新进入可执行状态。这种机制确保了同一时刻对于每一个类实例，其所有声明为 synchronized 的成员函数中至多只有一个处于可执行状态（因为至多只有一个能够获得该类实例对应的锁），从而有效避免了类成员变量的访问冲突（只要所有可能访问类成员变量的方法均被声明为 synchronized）。
在 Java 中，不光是类实例，每一个类也对应一把锁，这样我们也可将类的静态成员函数声明为 synchronized ，以控制其对类的静态成员变量的访问。
synchronized 方法的缺陷：若将一个大的方法声明为synchronized 将会大大影响效率，典型地，若将线程类的方法 run() 声明为 synchronized ，由于在线程的整个生命期内它一直在运行，因此将导致它对本类任何 synchronized 方法的调用都永远不会成功。当然我们可以通过将访问类成员变量的代码放到专门的方法中，将其声明为 synchronized ，并在主方法中调用来解决这一问题，但是 Java 为我们提供了更好的解决办法，那就是 synchronized 块。
2. synchronized 块：通过 synchronized关键字来声明synchronized 块。语法如下：
synchronized(syncObject) {
//允许访问控制的代码
}
synchronized 块是这样一个代码块，其中的代码必须获得对象 syncObject （如前所述，可以是类实例或类）的锁方能执行，具体机制同前所述。由于可以针对任意代码块，且可任意指定上锁的对象，故灵活性较高。
对synchronized(this)的一些理解
一、当两个并发线程访问同一个对象object中的这个synchronized(this)同步代码块时，一个时间内只能有一个线程得到执行。另一个线程必须等待当前线程执行完这个代码块以后才能执行该代码块。
二、然而，当一个线程访问object的一个synchronized(this)同步代码块时，另一个线程仍然可以访问该object中的非synchronized(this)同步代码块。
三、尤其关键的是，当一个线程访问object的一个synchronized(this)同步代码块时，其他线程对object中所有其它synchronized(this)同步代码块的访问将被阻塞。
四、第三个例子同样适用其它同步代码块。也就是说，当一个线程访问object的一个synchronized(this)同步代码块时，它就获得了这个object的对象锁。结果，其它线程对该object对象所有同步代码部分的访问都被暂时阻塞。
五、以上规则对其它对象锁同样适用
-
切面（Aspect）： 一个关注点的模块化，这个关注点可能会横切多个对象。事务管理是J2EE应用中一个关于横切关注点的很好的例子。 在Spring AOP中，切面可以使用通用类（基于模式的风格） 或者在普通类中以 @Aspect 注解（@AspectJ风格）来实现。
-
连接点（Joinpoint）： 在程序执行过程中某个特定的点，比如某方法调用的时候或者处理异常的时候。 在Spring AOP中，一个连接点 总是 代表一个方法的执行。 通过声明一个org.aspectj.lang.JoinPoint类型的参数可以使通知（Advice）的主体部分获得连接点信息。
-
通知（Advice）： 在切面的某个特定的连接点（Joinpoint）上执行的动作。通知有各种类型，其中包括“around”、“before”和“after”等通知。 通知的类型将在后面部分进行讨论。许多AOP框架，包括Spring，都是以拦截器做通知模型， 并维护一个以连接点为中心的拦截器链。
-
切入点（Pointcut）： 匹配连接点（Joinpoint）的断言。通知和一个切入点表达式关联，并在满足这个切入点的连接点上运行（例如，当执行某个特定名称的方法时）。 切入点表达式如何和连接点匹配是AOP的核心：Spring缺省使用AspectJ切入点语法。
-
引入（Introduction）： （也被称为内部类型声明（inter-type declaration））。声明额外的方法或者某个类型的字段。 Spring允许引入新的接口（以及一个对应的实现）到任何被代理的对象。 例如，你可以使用一个引入来使bean实现 IsModified 接口，以便简化缓存机制。
-
目标对象（Target Object）： 被一个或者多个切面（aspect）所通知（advise）的对象。也有人把它叫做 被通知（advised） 对象。 既然Spring AOP是通过运行时代理实现的，这个对象永远是一个 被代理（proxied） 对象。
-
AOP代理（AOP Proxy）： AOP框架创建的对象，用来实现切面契约（aspect contract）（包括通知方法执行等功能）。 在Spring中，AOP代理可以是JDK动态代理或者CGLIB代理。
-
织入（Weaving）： 把切面（aspect）连接到其它的应用程序类型或者对象上，并创建一个被通知（advised）的对象。 这些可以在编译时（例如使用AspectJ编译器），类加载时和运行时完成。 Spring和其他纯Java AOP框架一样，在运行时完成织入。
通知的类型：
-
前置通知（Before advice）： 在某连接点（join point）之前执行的通知，但这个通知不能阻止连接点前的执行（除非它抛出一个异常）。
-
返回后通知（After returning advice）： 在某连接点（join point）正常完成后执行的通知：例如，一个方法没有抛出任何异常，正常返回。
-
抛出异常后通知（After throwing advice）： 在方法抛出异常退出时执行的通知。
-
后通知（After (finally) advice）： 当某连接点退出的时候执行的通知（不论是正常返回还是异常退出）。
-
环绕通知（Around Advice）： 包围一个连接点（join point）的通知，如方法调用。这是最强大的一种通知类型。 环绕通知可以在方法调用前后完成自定义的行为。它也会选择是否继续执行连接点或直接返回它们自己的返回值或抛出异常来结束执行。
JAVA四种基本排序,包括冒泡法,插入法,选择法,SHELL排序法.其中选择法是冒泡法的改进,SHELL排序法是 插入法的改进.所以从根本上来说可以归纳为两种不同的排序方法:即:插入法＆冒泡法
一 插入法:遍历排序集合，每到一个元素时，都要将这个元素与所有它之前的元素遍历比较一遍，让符合排序顺序的元素挨个移动到当前范围内它最应该出现的位置。交换是相邻遍历移动，双重循环控制实现.这种排序法属于地头蛇类型,在我的地牌上我要把所有的东西按一定的顺序规整,过来一个,规整一个.
处理代码如下:
public void sort(int[] data) {
int temp;
for(int i=1; i〈data.length; i++){
for(int j=i; (j〉0)&&(data[j]〉data[j-1]); j--){
temp=date[j];
data[j]=data[j-1];
data[j-1]=temp;
}
}
}
二冒泡法:比较容易，它的内层循环保证遍历一次后，集合中最小（大）元素出现在它的正确位置，下一次就是次小元素。。。该方法在集合分布的各种情况下交换移动的次数基本不变，属于最慢的一种排序。实现也是双重循环控制。这种排序法属于过江龙,就是要找到极端,但是过奖龙也有大哥,二哥等,所以他们只能是大哥挑了二哥挑.
处理代码如下:
public static int [] maopao(int[] data) {
int temp;
for(int i=0; i〈data.length-1; i++){
for(int j=i+1; j〈data.length; j++){
if(data[i]〈data[j]){
temp=data[i];
data[i]=data[j];
data[j]=temp;
}
}
}
return data;
三选择法:该方法只是通过遍历集合记录最小（大）元素的位置，一次遍历完后，再进行交换位置操作，类似冒泡，但在比较过程中，不进行交换操作，只记录元素位置。一次遍历只进行一次交换操作。这个对与交换次序比较费时的元素比较适合。这种排序法比冒泡法要城府要深的多,我先记住极端数据,待遍历数据完了之后,我再处理,不像冒泡法那样只要比自己极端一点的就要处理,选择法只处理本身范围内的最极端数据.
public static void xuanze(int[] data) {
int temp;
for (int i = 0; i 〈 data.length; i++) {
int lowIndex = i;
for (int j = data.length - 1; j 〉 i; j--) {
if (data[j] 〉 data[lowIndex]) {
lowIndex = j;
}
}
temp=data[i];
data[i]=data[lowIndex];
data[lowIndex]=temp;
}
}
四 Shell排序：
它是对插入排序的一种改进，是考虑将集合元素按照一定的基数划分成组去排序，让每一组在局部范围内先排成基本有序，最后在进行一次所有元素的插入排序。
public void sort(int[] data) {
for(int i=data.length/2; i〉2; i/=2){
for(int j=0; j〈i; j++){
insertSort(data,j,i);
}
}
insertSort(data,0,1);
}
private void insertSort(int[] data, int start, int inc) {
int temp;
for(int i=start+inc; i〈data.length; i+=inc){
for(int j=i; (j〉=inc)&&(data[j]〈data[j-inc]); j-=inc){
temp=data[j];
data[j]=data[j-inc]
data[j-inc]=temp;
}
}
}
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1630773
越来越多人开始使用Java，但是他们大多数人没有做好足够的思想准备(没有接受OO思想体系相关培训)，以致不能很好驾驭Java项目，甚至 导致开发后的Java系统性能缓慢甚至经常当机。很多人觉得这是Java复杂导致，其实根本原因在于：我们原先掌握的关于软件知识(OO方面)不是太贫乏就是不恰当，存在认识上和方法上的误区。
软件的生命性
软件是有生命的，这可能是老调重弹了，但是因为它事关分层架构的原由，反复强调都不过分。
一个有生命的软件首先必须有一个灵活可扩展的基础架构，其次才是完整的功能。
目前很多人对软件的思想还是焦点落在后者：完整的功能，觉得一个软件功能越完整越好，其实关键还是架构的灵活性，就是前者，基础架构好，功能添加只是时间和工作量问题，但是如果架构不好，功能再完整，也不可能包括未来所有功能，软件是有生命的，在未来成长时，更多功能需要加入，但是因为基础架构不灵活不能方便加入，死路一条。
正因为普通人对软件存在短视误区，对功能追求高于基础架构，很多吃了亏的老程序员就此离开软件行业，带走宝贵的失败经验，新的盲目的年轻程序员还是使用老的思维往前冲。其实很多国外免费开源框架如ofbiz compiere和slide也存在这方面陷阱，貌似非常符合胃口，其实类似国内那些几百元的盗版软件，扩展性以及持续发展性严重不足。
那么选择现在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基础架构打好了呢？其实还不尽然，关键还是取决于你如何使用这些框架来搭建你的业务系统。
存储过程和复杂SQL语句的陷阱
首先谈谈存储过程使用的误区，使用存储过程架构的人以为可以解决性能问题，其实它正是导致性能问题的罪魁祸首之一，打个比喻：如果一个人频临死亡，打一针可以让其延长半年，但是打了这针，其他所有医疗方案就全部失效，请问你会使用这种短视方案吗？
为什么这样说呢？如果存储过程都封装了业务过程，那么运行负载都集中在数据库端，要中间J2EE应用服务器干什么？要中间服务器的分布式计算和集群能力做什么？只能回到过去集中式数据库主机时代。现在软件都是面向互联网的，不象过去那样局限在一个小局域网，多用户并发访问量都是无法确定和衡量，依靠一台数据库主机显然是不能够承受这样恶劣的用户访问环境的。（当然搞数据库集群也只是五十步和百步的区别）。
从分层角度来看，现在三层架构：表现层、业务层和持久层，三个层次应该分割明显，职责分明：持久层职责持久化保存业务模型对象，业务层对持久层的调用只是帮助我们激活曾经委托其保管的对象，所以，不能因为持久层是保管者，我们就以其为核心围绕其编程，除了要求其归还模型对象外，还要求其做其做复杂的业务组合。打个比喻：你在火车站将水果和盘子两个对象委托保管处保管，过了两天来取时，你还要求保管处将水果去皮切成块，放在盘子里，做成水果盘给你，合理吗？
上面是谈过分依赖持久层的一个现象，还有一个正好相反现象，持久层散发出来，开始挤占业务层，腐蚀业务层，整个业务层到处看见的是数据表的影子（包括数据表的字段），而不是业务对象。这样程序员应该多看看OO经典PoEAA。PoEAA 认为除了持久层，不应该在其他地方看到数据表或表字段名。
当然适量使用存储过程，使用数据库优点也是允许的。按照Evans DDD理论，可以将SQL语句和存储过程作为规则Specification一部分。
Hibernate等ORM问题
现在使用Hibernate人也不少，但是他们发现Hibernate性能缓慢，所以寻求解决方案，其实并不是 Hibernate性能缓慢，而是我们使用方式发生错误：
“最近本人正搞一个项目，项目中我们用到了struts1.2+hibernate3, 由于关系复杂表和表之间的关系很多，在很多地方把lazy都设置false，所以导致数据一加载很慢，而且查询一条数据更是非常的慢。”
Hibernate是一个基于对象模型持久化的技术，因此，关键是我们需要设计出高质量的对象模型，遵循DDD领域建模原则，减少降低关联，通过分层等有效办法处理关联。如果采取围绕数据表进行设计编程，加上表之间关系复杂（没有科学方法处理、侦察或减少这些关系），必然导致 系统运行缓慢，其实同样问题也适用于当初对EJB的实体Bean的CMP抱怨上，实体Bean是Domain Model持久化，如果不首先设计Domain Model，而是设计数据表，和持久化工具设计目标背道而驰，能不出问题吗？关于这个问题N多年就在Jdon争论过。
这里同样延伸出另外一个问题：数据库设计问题，数据库是否需要在项目开始设计？
如果我们进行数据库设计，那么就产生了一系列问题：当我们使用Hibernate实现持久保存时，必须考虑事先设计好的数据库表结构以及他们的关系如何和业务对象实现映射，这实际上是非常难实现的，这也是很多人觉得使用ORM框架棘手根本原因所在。
当然，也有脑力相当发达的人可以 实现，但是这种围绕数据库实现映射的结果必然扭曲业务对象，这类似于两个板块（数据表和业务对象）相撞，必然产生地震，地震的结果是两败俱伤， 软的一方吃亏，业务对象是代码，相当于数据表结构，属于软的一方，最后导致业务对象变成数据传输对象DTO, DTO满天飞，性能和维护问题随之而来。
领域建模解决了上述众多不协调问题，特别是ORM痛苦使用问题，关于ORM/Hibernate使用还是那句老话：如果你不掌握领域建模方法，那么就不要用Hibernate，对于这个层次的你：也许No ORM 更是一个简单之道： No ORM: The simplest solution
http://www.theserverside.com/blogs/thread.tss?thread_id=41715
Spring分层矛盾问题
Spring是以挑战EJB面貌出现，其本身拥有的强大组件定制功能是优点，但是存在实战的一些问题，Spring作为业务层框架，不支持业务层Session 功能。
具体举例如下：当我们实现购物车之类业务功能时，需要将购物场合保存到Session中，由于业务层没有方便的Session支持，我们只得将购物车保存到 HttpSession，而HttpSession只有通过HttpRequest才能获得，再因为在Spring业务层容器中是无法访问到HttpRequest这个对象的，所以， 最后我们只能将“购物车保存到HttpSession”这个功能放在表现层中实现，而这个功能明显应该属于业务层功能，这就导致我们的Java项目层次混乱，维护性差。 违背了使用Spring和分层架构最初目的。
相关案例：请教一个在完整提交前临时保存的问题:
http://www.jdon.com/jive/article.jsp?forum=46&thread=28429
领域驱动设计DDD
现在回到我们讨论的重点上来，分层架构是我们使用Java的根本原因之一，域建模专家Eric Evans在他的“Domain Model Design”一书中开篇首先强调的是分层架构，整个DDD理论实际是告诉我们如何使用模型对象oo技术和分层架构来设计实现一个Java项目。
我们现在很多人知道Java项目基本有三层：表现层 业务层和持久层，当我们执著于讨论各层框架如何选择之时，实际上我们真正的项目开发工作还没有开始， 就是我们选定了某种框架的组合（如Struts+Spring+Hibernate或Struts+EJB或Struts+JdonFramework），我们还没有意识到业务层工作还需要大量工作，DDD提供了在业务层中再划分新的层次思想，如领域层和服务层，甚至再细分为作业层、能力层、策略层等等。通过层次细化方式达到复杂软件的松耦合。DDD提供了如何细分层次的方式
当我们将精力花费在架构技术层面的讨论和研究上时，我们可能忘记以何种依据选择这些架构技术？选择标准是什么？领域驱动设计DDD 回答了这样的问题，DDD会告诉你如果一个框架不能协助你实现分层架构，那就抛弃它，同时，DDD也指出选择框架的考虑目的，使得你不会 人云亦云，陷入复杂的技术细节迷雾中，迷失了架构选择的根本方向。
现在也有些人误以为DDD是一种新的理论，其实DDD和设计模式一样，不是一种新的理论，而是实战经验的总结，它将前人 使用面向模型设计的方法经验提炼出来，供后来者学习，以便迅速找到驾驭我们软件项目的根本之道。
现在Evans DDD概念很火，因为它将著名的PoEAA进行了具化，实现了PoEAA可操作性，这也是MF大力推崇的原因。最近(8月8日)一位老外博客上用微软的.NET架构和Evans DDD比较的文章：http://weblogs.asp.net/pgielens/archive/2006/08/08/Organizing-Domain-Logic.aspx，这篇文章比较了微软的三层服务应用架构[Microsoft TLSA]和Evans DDD的架构， 使用Microsoft .NET Pet Shop 4为例子，解释两个目标的区别，并且表明
微软是如何在案例中更好地实现支持后者。这篇文章帮助哪些.NET平台上有域设计知识的人实现更好地提高。
另外一本关于.NET的DDD书籍也已经出版，这些都说明Evans DDD这把火已经烧到.NET领域，当然DDD在Java领域生根开花多年，Evans的DDD书籍就是以Java为例子的，笔者板桥里人也率先在2005年推出DDD框架JdonFramework 1.3版本，这些都说明，Java在整个软件业先进思想的实践上总是领先一步。
参考文章：
面向对象与领域建模
实战DDD(Domain-Driven Design领域驱动设计)
领域模型驱动设计(DDD)之模型提炼
数据库时代的终结
Java EE/J2EE面向对象编程之道
更多关于DDD讨论
更多关于EJB3讨论
更多关于IOC讨论
更多关于AOP讨论
更多关于Spring讨论
更多关于JdonFramework讨论
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1630894
摘要: 总结了Hibernate提供的所有主键生成器，比较个生成器使用时机，并且列举一个自定义主键生成器实例。
阅读全文
摘要: 3：区分逻辑层（layer）和物理层（tier）
阅读全文