如何使用jsp的 DOM4J 读取解析 xml文件 http://www.111cn.net/jsp/49/33290.htm

ArrayList和LinkedList区别

   对于处理一列数据项,Java提供了两个类ArrayList和LinkedList,ArrayList的内部实现是基于内部数组Object[],所以从概念上讲,它更象数组，但LinkedList的内部实现是基于一组连接的记录,所以,它更象一个链表结构，所以,它们在性能上有很大的差别。
   从上面的分析可知,在ArrayList的前面或中间插入数据时,你必须将其后的所有数据相应的后移,这样必然要花费较多时间，所以,当你的操作是在一列数据的后面添加数据而不是在前面或中间,并且需要随机地访问其中的元素时,使用ArrayList会提供比较好的性能
   而访问链表中的某个元素时,就必须从链表的一端开始沿着连接方向一个一个元素地去查找,直到找到所需的元素为止，所以,当你的操作是在一列数据的前面或中间添加或删除数据,并且按照顺序访问其中的元素时,就应该使用LinkedList了。
   如果在编程中,1，2两种情形交替出现,这时,你可以考虑使用List这样的通用接口,而不用关心具体的实现，在具体的情形下,它的性能由具体的实现来保证。
   配置集合类的初始大小
   在Java集合框架中的大部分类的大小是可以随着元素个数的增加而相应的增加的，我们似乎不用关心它的初始大小,但如果我们考虑类的性能问题时,就一定要考虑尽可能地设置好集合对象的初始大小,这将大大提高代码的性能。
   比如,Hashtable缺省的初始大小为101,载入因子为0.75,即如果其中的元素个数超过75个,它就必须增加大小并重新组织元素，所以,如果你知道在创建一个新的Hashtable对象时就知道元素的确切数目如为110,那么,就应将其初始大小设为110/0.75=148,这样,就可以避免重新组织内存并增加大小。

TreadLocal实例分析

http://lavasoft.blog.51cto.com/62575/51926

http://www.blogjava.net/pengpenglin/archive/2008/09/05/227276.html

ThreadLocal的核心思想很简单：为每个独立的线程提供一个变量的副本。

我们知道在多线程的情况下，几个线程同时访问同一变量的情况很常见，Java提供的synchronized关键字使用了“同步锁”的机制来阻止线程的竞争访问，即“以时间换空间”。

ThreadLocal则使用了“拷贝副本”的方式，人人有份，你用你的，我用我的，大家互不影响，是“以空间换时间”。每个线程修改变量时，实际上修改的是变量的副本，不怕影响到其它线程。

ThreadLocal的一个最常见应用是为每个线程分配一个唯一的ID，例如线程ID，事务ID，一般保存在ThreadLocal中的变量都是很少需要修改的。

为了加深对ThreadLocal的理解，下面我使用一个例子来演示ThreadLocal如何隔离线程间的变量访问和修改：

【1】SerialNum类

package example.thread.threadLocal; public class SerialNum { private static int nextSerialNum = 1 ; @SuppressWarnings( " unchecked " ) private static ThreadLocal serialNum = new ThreadLocal() { protected synchronized Object initialValue() { return new Integer(nextSerialNum ++ ); } }; public static int get() { return ((Integer) (serialNum.get() )).intValue(); } @SuppressWarnings( " unchecked " ) public static void set(Integer newSerial){ serialNum.set(newSerial); } }

【2】GetSerialNumThread

package example.thread.threadLocal; public class GetSerialNumThread implements Runnable { public static void main(String args[]) { GetSerialNumThread serialNumGetter = new GetSerialNumThread(); Thread t1 = new Thread(serialNumGetter, " Thread A " ); Thread t2 = new Thread(serialNumGetter, " Thread B " ); t1.start(); try { t1.join(); } catch (InterruptedException e) { e.printStackTrace(); } t2.start(); } public void run() { int mySerialNum = getSerialNum(); System.out.println( " 线程 " + Thread.currentThread().getName() + " 获取到的序列号是 " + mySerialNum); System.out.println( " 线程 " + Thread.currentThread().getName() + " 修改了序列号为 " + (mySerialNum * 3 )); setSerialNum(mySerialNum * 3 ); System.out.println( " 线程 " + Thread.currentThread().getName() + " 再次获得的序列号是 " + getSerialNum()); } private int getSerialNum() { return SerialNum.get(); } private void setSerialNum( int newSerialNum) { SerialNum.set( new Integer(newSerialNum)); } }

运行的结果如下：

线程 Thread A 获取到的序列号是1
线程 Thread A 修改了序列号为3
线程 Thread A 再次获得的序列号是3
线程 Thread B 获取到的序列号是2
线程 Thread B 修改了序列号为6
线程 Thread B 再次获得的序列号是6

http://www.mylearning.cc/

书籍

http://www.adempiere.com/ZH/Case-Study-01-Journal-22

http://www.itpub.net/thread-256507-1-1.html

http://www.ooppoo.com/html/88/n-260188.html

一.Struts2 的简介
** 虽然 struts2 号称是一个全新的框架,但是这仅仅是相对于 struts1 而言的.
** Struts2 和 struts1 相比,确实有很多革命性的改进,但是并不是新发布的新框架.二是另一个框架 WebWork 基础上发展起来的.
** Struts2 没有继承 struts1 的血统,而是继承 webWork 的血统.
** struts2是 WebWork 的升级,而不是一个全新的框架,稳定性和性能等各方面都有很好的保证
** 而且吸收了 struts1 和 WebWork 两者的优势,因此是一个非常值得期待的框架
二. Apache Struts2 是一个可扩展的 Java EE WEB框架. 框架设计的目标贯穿整个开发的周期
三. Struts2 和 Struts1 的不同
** Action类:
- Struts1 要求 Action 类继承一个抽象基类. Struts1 的一个普遍的问题是使用抽象类编程而不是接口
- Struts2 Action 类可以实现一个 Action 接口,也可实现其他的接口,使可选和定制的服务称为可能.
- Struts2 提供了一个 ActionSupport 基类去实现常用的接口; Action接口不是必须的,任何有 execute 标识的POJO
对象都可以用作 Struts2 的 Action 对象
** 线程模式:
- Struts1 Action 是单例的模式并且必须是线程安全的,因为仅有 Action 的一个实例来处理所有的请求.单例的策略限制了
Struts1 Action 能做的事情,并且要在开发的时候特别的小心. Action 资源必须是线程安全或者同步的
- Struts2 Action 对象为每一个请求产生一个实例,因此没有线程安全的问题
** Servlet依赖:
- Struts1 Action 依赖于 Servlet API,因为当一个Action被调用 HttpServletRequest 和 HttpServletResponse 被传递给 execute() 方法
- Struts2 Action 不依赖于容器,允许 Action 脱离容器单独的被测试.如果需要的话 Struts2 Action 仍然可以访问初始的 request 和 response
但是,其他的元素减少或者消除了直接访问 HttpServletRequest 和 HttpServletResponse 的必要性
** 可测性:
- Struts1 Action 测试的一个主要的问题是 execute 方法暴露了 Servlet API (使得测试要依赖容器).一个第三方的扩展
Struts TestCase -- 提供了一套 Struts1 的模拟对象 (来进行测试)
- Struts2 Action 可以通过初始化, 设置属性,调用方法来测试 "依赖注入" 支持也使得测试更加的容易
** 捕获输入:
- Struts1 Action 使用ActionForm对象来捕获输入.所有的 ActionForm 必须继承一个基类.因为其他的JavaBean 不能用作
ActionForm ,开发者经常创建多余的类捕获输入.动态的 Bean (DynaBeans) 可以作为创建传统的ActionForm选择,但是,开发者可能是在重新描述(创建)已经存在的 JavaBean
会导致冗余的 JavaBean)
- Struts2 Action 直接使用 Action 属性作为输入的属性,消除了对第二个输入对象的需求. Action 属性能够通过web页面上的
taglibs 访问. Struts2 也支持 ActionForm 模式
** 表达式语言:
- Struts1 整合了 JSTL ,因此使用 JSTL EL .这种EL 的基本的对象图遍历,但是对集合和索引属性的支持很弱
- Struts2 可以使用 JSTL ,但是也支持一个更强大的和灵活的表达式语言 -- "Object Graph Notation Language" (OGNL)
** 绑定值到页面 (view) :
- Struts1 使用标准 JSP 机制把对象绑定到页面来访问
- Struts2 使用 "ValueStack" 技术,使 taglib 能够访问值而不需要把你的页面 (view) 和对象绑定起来
ValueStack 策略允许通过一些列的名称相同但是类型不同的属性重用页面 (view)
** 类型的转换 :
- Struts1 ActionForm 属性通常都是 String 类型的. Struts1使用 Commons-Beanutils 进行类型的转换
每个类一个转换器,对每一个实例来说是不可配置的
- Struts2 使用OGNL 进行类型的转换. 提供基本的和常用的对象的转换器
** 校验 :
- Struts1 支持在 ActioNForm 的 validate 方法中手动的校验,或者通过 Commons Validator 的扩展来校验.
同一个类可以有不同的校验内容,但不能校验子对象
- Struts2 支持通过 validate 方法和 XWork 校验框架来进行校验. XWork 校验框架使用为属性类类型定义的校验和内容校验
来支持 chain 校验子属性
** Action 执行的控制 :
- Struts1 支持每一个模块有单独的 Request Processors (生命周期);但是模块中的所有的 Action 必须功效那个相同的生命周期
- Struts2 支持通过拦截器堆栈 (Interceptor Stacks) 为每一个 Action 创建不同的生命周期.
堆栈能够根据需要和不同的 Action 一起使用

四. Eclipse 中继承 Struts2
** commons-logging-1.0.4.jar
Struts2框架的日志包
** freemarker-2.3.8.jar
Struts2的 UI 标签的模板
** ognl-2.6.11.jar
对象导航语言包
** struts2-core.2.0.11.jar
Struts框架的核心包
** xwork-2.0.4.jar
XWork类库,Struts2 基于此构建
五. 案例
**1 基于 Struts2 创建一个简单的登陆项目
**2 导入 Struts2 核心支持包
**3 在 web.xml 中配置 FilterDispatcher
**4 开发 DAO
**5 开发 action
**6 编写前台显示的页面
**7 创建 struts.xml
六. Struts2 处理用户输入信息
**1. 利用 action 类的属性接受用户输入
**2. 利用领域对象接受用户输入
**3. 使用 ModelDriver 模式接受用户输入

设计模式之Singleton(单态)

http://www.jdon.com/designpatterns/singleton.htm

单态定义:
Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存在。

在很多操作中，比如建立目录数据库连接都需要这样的单线程操作。

还有, singleton能够被状态化; 这样，多个单态类在一起就可以作为一个状态仓库一样向外提供服务，比如，你要论坛中的帖子计数器，每次浏览一次需要计数，单态类能否保持住这个计数，并且能synchronize的安全自动加1，如果你要把这个数字永久保存到数据库，你可以在不修改单态接口的情况下方便的做到。

另外方面，Singleton也能够被无状态化。提供工具性质的功能，

Singleton模式就为我们提供了这样实现的可能。使用Singleton的好处还在于可以节省内存，因为它限制了实例的个数，有利于Java垃圾回收（garbage collection）。

我们常常看到工厂模式中类装入器(class loader)中也用Singleton模式实现的,因为被装入的类实际也属于资源。

如何使用?
一般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实例。关于lazy initialization的Singleton有很多涉及double-checked locking (DCL)的讨论，有兴趣者进一步研究。

一般认为第一种形式要更加安全些。

使用Singleton注意事项：
有时在某些情况下，使用Singleton并不能达到Singleton的目的，如有多个Singleton对象同时被不同的类装入器装载；在EJB这样的分布式系统中使用也要注意这种情况，因为EJB是跨服务器，跨JVM的。

我们以SUN公司的宠物店源码(Pet Store 1.3.1)的ServiceLocator为例稍微分析一下：

在Pet Store中ServiceLocator有两种，一个是EJB目录下；一个是WEB目录下，我们检查这两个ServiceLocator会发现内容差不多，都是提供EJB的查询定位服务，可是为什么要分开呢？仔细研究对这两种ServiceLocator才发现区别：在WEB中的ServiceLocator的采取Singleton模式，ServiceLocator属于资源定位，理所当然应该使用Singleton模式。但是在EJB中，Singleton模式已经失去作用，所以ServiceLocator才分成两种，一种面向WEB服务的，一种是面向EJB服务的。

Singleton模式看起来简单，使用方法也很方便，但是真正用好，是非常不容易，需要对Java的类线程内存等概念有相当的了解。

总之：如果你的应用基于容器，那么Singleton模式少用或者不用，可以使用相关替代技术。

进一步深入可参考：

Double-checked locking and the Singleton pattern

When is a singleton not a singleton?

单例模式请不要滥用

http://www.nowamagic.net/program/program_DoNotAbuseSingleTon.php

说到面向对象的设计模式，现在很多人都可以随便说出好几种常用的，但是有没有想过设计模式，即使是初学者也至少能说一下SingleTon和Factory Method这两个。那么，设计模式是不是随便怎么用都没问题哪？

这个问题从提问的方式上就可以看出，答案一定是否定的（大家也不是白白接受了这么多年的应试教育的）。但是，就我个人的观察，滥用设计模式的绝对不是少数。而且越是简单的模式越会被滥用。

从最简单的模式——SingleTon开始。

说到SingleTon，我相信只要知道设计模式的，就知道SingleTon，也写过SingleTon，可谓是尽人皆知的设计模式了。就是这个尽人皆知的设计模式，却是被滥用的最厉害的设计模式，本篇就讨论一下关于SingleTon的滥用问题。

线程安全是个问题

首先GoF是站在一个纯OO的领域思考问题的，所以，很多其他领域的问题并没有考虑进来（事实上也不适合拉进来一起讲），然而实际编程者却不得不面对更多领域的问题（最常见的是并发领域）。这也就是为什么在GoF的SingleTon是如此的简单，而在Java或.net实际写SingleTon时，却需要注意锁的问题的根本原因。关于SingleTon是否是线程安全的，我倾向于把问题分解成两个部分：

SingleTon本身是否线程安全
SingleTon的实例是否线程安全

关于第一个，通过著名的Java下双检锁不安全问题，相信大家都已经十分清楚了，如果还有不清楚的，请查阅相关资料，本文就不再重复了。在这里，要重点说的是第二个问题，SingleTon的实例是否线程安全。

如果仔细看msdn的话，在大多数类上，msdn都写了这么一句话：Public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

在msdn中文版中是：此类型的公共静态（在 Visual Basic 中为 Shared）成员是线程安全的。但不能保证任何实例成员是线程安全的。

在ms给出的类库，把静态成员都写成线程安全的，而对待大部分的实例成员却是放任其线程的不安全，而要求开发人员在开发时处理实例成员的线程不安全问题（我相信Java的类库也是类似的做法）。

那么在多线程程序中使用SingleTon，会引出什么问题哪？首先，SingleTon仅仅允许一个类只有一个实例。那么这里简单的做个推理：

在这个程序里面无论何时，当你需要这个类的实例的时候，都只能使用这个唯一的实例。
无论在这个程序的哪个线程中，当你需要这个类的实例的时候，都只能使用这个唯一的实例。
无论在这个程序中出现什么样的并发，当你需要这个类的实例的时候，都只能使用这个唯一的实例。
无论在这个程序中出现什么样的并发，当你需要调用这个类的实例的某个成员时，都只能使用这个唯一的实例的成员。
无论在这个程序中出现什么样的并发，为了保证程序是线程安全的，当你需要调用这个类的实例的某个成员时，都只能使用这个唯一的实例的成员，并且需要保证其线程安全。
无论在这个程序中出现什么样的并发，为了保证程序是线程安全的，当你需要调用这个类的实例的某个成员时，如果这个成员不是线程安全的，那么在使用这个唯一的实例的成员时都需要正确的线程同步。

发现问题了没有，被SingleTon的实例成员的线程安全性需要谁来保证？

选项A：SingleTon的实例保证所有的成员是线程安全的
选项B：SingleTon的实例不保证线程安全的，请大家在使用的时候都加上锁

如果选择A，那么，请检查那些被SingleTon的代码，看看有没有用到堆，检查对堆的任何调用是否都是线程安全的，或者已经同步的。

如果选择B，那么，请检查所有使用SingleTon的代码，看看是否都经过了可靠的线程同步（例如Lock那个SingleTon的对象），只要有一处不注意，就导致整个是线程不安全的（但是当下这么多写网页的人，有多少人会去关注那些资源是需要线程同步的吗？）。

有没有选项C？有，如果是类库的话，对外宣称程序是线程不安全的，请在使用前保证线程安全（例如COM中著名的STA）；如果是应用程序的话就告诉客户，本程序是线程不安全的，出任何问题都是有可能的，当初合同就没说要保证线程安全（客户一定会抓狂）。

为什么要用SingleTon？

不知道大家有没有想过，当初为什么要把这个类型用SingleTon来做。我看到的大多数答案是节省资源和全局状态，固定算法的接口适配（不排除还有更好的答案）。

先讨论节省资源的问题，首先不new实例一定比new实例要节省资源（CPU和内存），这点不用质疑，但是如果要做到线程安全，似乎就要再考量一下了。

如果SingleTon实例本身的实现方式就保证了线程安全（仅使用堆栈和参数中的对象，对自身引用的对象只读），那么线程安全是0代价的。如果其实现方式涉及Lock等同步，那么冲突概率是多少，如果冲突概率足够的高，那么大多数时间线程将进入等待状态，导致大量占用时间资源和CPU资源。即使冲突概率很低，由于Lock需要同步Cache和内存，所以一样需要花费一些额外的代价（同步Cache的时间代价）。

说到这里，还觉得有Lock的SingleTon一定比new实例节省资源？未必吧，到底谁省资源还是要具体问题具体分析一下，不Profiling一下，谁又知道结果哪？

至于全局状态，可以的话，要尽量避免全局状态的使用，如果必须要使用的话，确实没什么好的方案，不过，建议作为全局状态使用的SingleTon需要保证所有成员的线程安全（否则，一个team member的小错误，就可能导致全局状态出错）。

第三种固定算法的接口适配，这是我比较提倡的SingleTon用法。这里涉及几个部分的要求：

算法固定
算法不存在状态，所有的变化均来自参数，且实现无需线程同步就可以保证线程安全
接收方要求符合某接口（泛指）

如果第一点不满足，那就不可能作为SingleTon存在。第二点是确保使用SingleTon的性能优势。而第三点是OO立场上的SingleTon必要性，否则为什么不用静态方法。

也许这3点比较抽象，举个实际点的例子：

 
       01 
        public class PersonNameComparer   
      
       02 
            : IComparer<Person>   
      
       03 
       {  
      
       04 
            public int Compare(Person x, Person y)   
      
       05 
            {   
      
       06 
                if (x == y)   
      
       07 
                    return 0;   
      
       08 
                if (x == null)   
      
       09 
                    return -1;   
      
       10 
                if (y == null)   
      
       11 
                    return 1;   
      
       12 
                return string.Compare(x.name, y.name);   
      
       13 
            }   
      
       14 
       }

第一，算法固定，就是比较2个人的名字，没有第二种算法，要是有那也是其它类的职责；第二，不存在状态，只用了x和y两个参数，没有线程同步；第三，因为需要在排序的场合需要IComparer<Person>接口的实例，因此不能使用静态方法（假设不能使用委托）。

因此，这个类型如果是SingleTon的话，那将是合理的（当然这里不用SingleTon也没问题）。

后话

N年前，我去面试某公司时，某面试官问我数据库联接能不能做SingleTon，我说不能，会引入很多问题，结果面试官很不满意。

N月前，面试某人，在谈到设计模式用在什么地方时候，举例说在Web项目中把一个WebService的代理类做成了SingleTon，结果我很不满意。哎，SingleTon啊SingleTon，真是GoF引入OO的最大的坑。

随机文章推荐

网站分类

HTML (44)
CSS (105)
JavaScript (232)
JQuery (53)
Ajax (34)
PHP (314)
Java (39)
C/C++ (35)
ActionScript (21)
PhotoShop (4)
XML (1)
WordPress (9)
数据结构 (14)
计算机算法 (56)
数据库技术 (66)
操作系统 (1)
互联网时代 (160)
软件项目 (27)
编程思想 (57)
搜索引擎优化 (31)
Web设计理念 (77)
软件架构技术 (31)
信息化工具 (12)
广告设计 (7)
程序人生 (18)
喃喃细语 (61)