<script>

function sqrt(x) {
    return x * x;
}
function other(f) {
    var y = f(10);
    return y;
}

var farr = new Array();
farr[0] = function(arg) { return arg + arg;};
farr[1] = function(arg) { return arg * arg;};

document.write(farr[0](10) + '<br/>');
document.write(farr[1](10));

document.write(other(sqrt));

</script>

sqrt.count = 0;
sqrt.getcount = function() {
                    return this.count;
                }; // 附加函式

//sqrt();
document.write(sqrt.count, '<br/>');
document.write(sqrt.getcount());

创建模式(Creational Patterns)
Abstract Factory Builder
Factory Method  Prototype
Singleton

结构模式(Structural Patterns)
Adapter  Bridge
Composite Decorator
Facade  Flyweight
Proxy

行为模式(Behavioral Pattern)
Chain of Responsibility  Command
Interpreter   Iterator
Mediator   Memento
Observer   State
Strategy   Template Method
Visitor

一、创建模式(Creational Patterns)

1.Abstract Factory(抽象工厂)—把相关零件组合成产品
 Abstract Factory Pattern 是把各种抽象零件组合成抽象产品。换句话说，处理的重点是在接口(API)而不是零件的具体实现。只利用接口(API)就能把零件组合成产品.
 程序示例:
 --Main.java 测试用的类
 |-factory
 |    |-------Factory.java 表示抽象工厂的类(产生Link,Tray,Page)
 |    |-------Itme.java 用来统一处理Link和Tray的类
 |    |-------Link.java 抽象零件:表示HTML连接的类
 |    |-------Tray.java 抽象零件:抽取Link和Tray的类
 |    |-------Page.java 抽象零件:表示HTML网页的类
 |
 |-listfactory
      |-------listFactory.java 表示具体工厂的类(产生ListLink,ListTray,ListPage)
      |-------listLink.java 具体零件:表示HTML连接的类
      |-------listTray.java 具体零件:抽取Link和Tray的类
      |-------listPage.java 具体零件:表示HTML网页的类
 步骤:定义抽象零件->用抽象零件定义抽象工厂->定义具体零件(继承实现抽象零件)->定义具体工厂(继承实现抽象工厂,制造实际产品)

2.Factory Method
 Factory Method Pattern 在父类规定对象的创建方法,但并没有深入到较具体的类名.所有具体的完整内容都放在子类.根据这个原则,我们可以大致分成产生对象实例的大纲(框架)和实际产生对象实例的类两方面.
 程序示例:
 --Main.java 测试用的类
 |-framework
 |    |-------Product.java 仅定义抽象方法use的抽象类
 |    |-------Factory.java 规定createProduct,registerProduct,实现create的抽象类(类似模板方法)
 |
 |-idcard
      |-------IDCard.java 实现方法use的具体类
      |-------IDCardFactory.java 实现方法createProduct,registerProduct的类
 步骤:定义抽象产品->根据抽象产品定义抽象工厂->定义具体产品(继承实现抽象产品)->定义具体工厂(继承实现抽象工厂,制造实际产品)

3.Singleton(单件)－唯一的对象实例
 Singleton Pattern 是针对一个类而言. Singleton类只会产生１个对象实例．Singleton类把singleton定义为static字段(类变量),再以Singleton类的对象实例进行初始化．这个初始化的操作仅在加载Singleton类时进行一次．
 Singleton类的构造函数是private的，主要是为了禁止从非Singleton类调用构造函数．即使下面这个表达式不在此类之内，编译时仍然会出现错误．
  程序示例:
 |--Main.java 测试用的类
 |--Singleton.java 只有１个对象实例的类
 步骤:定义一个该类类型的static字段，同时实例化->该类的构造方法设为private->定义一个static的getInstance()方法，返回已经实例化的static字段．

4.Builder(生成器)－组合复杂的对象实例
 Builder Pattern 是采用循序渐进的方式组合较复杂对象实例的．
 程序示例:
 |--Main.java 测试用的类
 |--Builder.java 规定建立文件时的方法的抽象类
 |--Director.java 产生１个文件的类
 |--TextBuilder.java 产生plaintext格式(一般文本格式)的类
 |--HTMLBuilder.java 产生HTML格式的类
 步骤:定义建立文件时的通用方法(Builder.java)->根据通用方法组织建立文件(Director.java)->根据不同需求实现建立文件的通用方法(TextBuilder.java,HTMLBuilder.java)

5.Prototype(原型)－复制建立对象
 Prototype Pattern 不是利用类产生对象实例，而是从一个对象实例产生出另一个新对象实例．
 程序示例:
 |--Main.java 测试用的类
 |--MessageBox.java 把字符串框起来use的类．实现use和createClone
 |--UnderlinePen.java 把字符串加上下划线的类．实现use和createCone
 |--framework
      |-------Product.java 已声明抽象方法use和createClone的接口
      |-------Manager.java 利用createClone复制对象实例的类
 步骤:规定可复制产品的接口(Product.java,继承Cloneable接口)->保存可复制的产品(以Product类型存以哈西表中)，并提供复制产品的方法create(调用产品的复制方法，复制工作在具体产品类中执行)(Manager.java)->定义可复制的具体产品(UnderlinePen.java,MessageBox.java,实现复制产品方法)

二、结构模式(Structural Patterns)

1.Adapter(适配器)－换个包装再度利用
 Adapter Pattern 把既有的无法直接利用的内容转换成必要的类型后再使用．具有填平＂既有内容＂和＂需要结果＂两者间＂落差＂的功能．
 Adapter Pattern 有继承和委托两种形式．
 程序示例:
 |--Main.java 测试用的类
 |--Banner.java 具有原始功能showWithParen,showWithAster的类
 |--Print.java 所需新功能printWeak,printStrong的接口或抽象类
 |--PrintBanner.java 把原始功能转换成新功能的类
 步骤:
 (继承)构造具有原始功能的类(Banner.java)->定义具有新功能的接口(Print.java)->转换(PrintBanner.java,继承Banner实现Print接口,即继承旧方法实现新功能)
 (委托)构造具有原始功能的类(Banner.java)->定义具有新功能的抽象类(Print.java)->转换(PrintBanner.java,继承具有新功能的Print类.定义委托对象,即原始功能类.构造时传入原始功能实例对象，新功能的实现利用委托对象的原始功能．)

2.Bridge(桥接)－分成功能层次和实现层次
 Bridge Pattern 沟通着＂功能的类层次＂和＂实现的类层次＂
 功能的类层次：给父类增加不同的功能
 实现的类层次：给父类以不同的实现
 Bridge Pattern 本质上是通过功能类(最上层的功能类)中的一个实现类(最上层的实现类，一般是抽象类)字段来桥接两个类层次的．
 程序示例:
 |--Main.java 测试用的类
 |--Display.java 功能类层次的最上层类
 |--CountDisplay.java 功能类层次的新增功能类
 |--DisplayImpl.java 实现类层次的最上层类
 |--StringDisplayImpl.java 实现类层次的实现类
 步骤:定义实现类层次的最上层类(DisplayImpl.java)->定义功能类层次的最上层类(Display.java,使用Adapter Pattern的委托方式把DisplayImpl.java的原始功能转换成Display.java的新功能)->定义功能类层次的新增功能类(CountDisplay.java)->定义实现类层次的实现类(StringDisplayImpl.java)

3.Composite(组成)-对容器和内容一视同仁
 有时候把容器和内容当作是同类来处理会比较好下手。容器里面可以是内容，也可以是更小一号的容器；而这个小一号的容器里还可以再放更小一号的容器，可以建立出像这样大套小的结构和递归结构的Pattern就是Composite Pattern
 使用Composite Pattern,容器和内容必须有一定的共性.
 程序示例:
 |--Main.java 测试用的类
 |--File.java 表示文件的类
 |--Directory.java 表示目录的类
 |--Entry.java 对File和Directory一视同仁的抽象类
 |--FileTreatmentException.java 欲在文件内新增Entry时所发生的异常类
 步骤:定义异常类(FileTreatmentException.java)->定义进入点类,即将容器和内容一视同仁的抽象类(Entry.java,容器和内容都含有共同的方法)->定义容器类和内容类(File.java,Directory.java,继承Entry,实现通用方法)

4.Decorator(装饰)-对装饰和内容一视同仁
 先建立一个核心对象,再一层层加上装饰用的功能,就可以完成符合所需的对象.可以看成是多个通用的适配器.
 程序示例:
 |--Main.java 测试用的类
 |--Display.java 打印字符串用的抽象类
 |--StringDisplay.java 只有1行的打印字符串用的类
 |--Border.java 表示"装饰外框"的抽象类
 |--SideBorder.java 只在左右加上装饰外框的类
 |--FullBorder.java 在上下左右加上装饰外框的类
 步骤:定义核心对象的抽象类(Display.java)->定义核心对象类(StringDisplay.java)->定义装饰类的抽象类(Border.java,继承核心对象的抽象类Display.java,以便装饰和内容一视同仁.装饰类中继承自核心对象抽象类的方法委托给传入的核心对象)->定义其它装饰类(SideBorder.java,FullBorder.java,继承Border.java)

5.Facade(外观)-单一窗口
 Facade Pattern 能整理错综复杂的来龙去脉,提供较高级的接口(API).Facade参与者让系统外部看到较简单的接口(API).而且Facade参与者还会兼顾系统内部各类功能和互动关系,以最正确的顺序利用类.
 Facade Pattern 把业务逻辑封装起来,只提供一个简单的接口给外部调用.
 程序示例:
 |--Main.java 测试用的类
 |--maildata.txt 邮件列表文件
 |--pagemaker
       |-------Database.java 从邮件信箱取得用户名称的类
       |-------HtmlWriter.java 产生HTML文件的类
       |-------PageMaker.java 根据邮件信箱产生用户网页的类
 步骤:定义业务逻辑需要的相关类(Database.java,HtmlWriter.java)->定义外部接口类(PageMaker.java)

6.Flyweight(享元)-有相同的部分就共享,采用精简政策
 "尽量共享对象实例,不做无谓的new".不是一需要对象实例就马上new,如果可以利用其他现有的对象实例,就让它们共享.这就是Flyweigth Pattern的核心概念.
 Flyweight Pattern 实质是把创建的占用内存量大的对象存储起来(一般用hashtable存储),后续使用时,再从hashtable取出.
 程序示例:
 |--Main.java 测试用的类
 |--BigChar.java 表示"大型字符"的类
 |--BigCharFactory.java 共享并产生BigChar的对象实例的类
 |--BigString.java 表示多个BigChar所产生的"大型文本"的类
 步骤:定义占用内存量大,需要共享的类(Display.java)->定义共享实例的类(BigCharFactory.java,共享处理在此进行,将产生的共享对象存储在哈希表中,第二次使用时从表中取出即可,不需要new)->定义共享对象组合使用类(BigString.java)

7.Proxy(代理)-需要再建立
 代理就是那个代替本来应该自己动手做事的本人的人.
 由于代理纯粹只是代理工作而已,因此能力范围也有限.如果遇到超出代理能力所及的范围,代理就应该去找本人商量才对.
 程序示例:
 |--Main.java 测试用的类
 |--Printer.java 表示命名的打印机的类(本人)
 |--Printable.java Printer和PrinterProxy共享的接口
 |--PrinterProxy.java 表示命名的打印机的类(代理)
 步骤:定义本人和代理都能处理的问题的接口(Printable.java)->建立本人类(Printer.java,实现Printable.java接口)->建立代理类(PrinterProxy.java,定义本人字段,把代理无法处理的问题交给本人)

三、行为模式(Behavioral Pattern)

1.Chain of Responsibility(职责链)-责任转送
 先对人产生一个要求,如果这个人有处理的能力就处理掉;如果不能处理的话,就把要求转送给"第二个人".同样的,如果第二个人有处理的能力时就处理掉,不能处理的话,就继续转送给"第三个人",依此类推.这就是Chain of Responsiblility Pattern.
 Chain of Responsibility Pattern 的关键在于定义转送字段(next)和定义职责链.
 程序示例:
 |--Main.java 建立Support的连锁,产生问题的测试用类
 |--Trouble.java 表示发生问题的类.内有问题编号.
 |--Support.java 解决问题的抽象类.内有转送字段和处理方法.
 |--NoSupport.java 解决问题的具体类(永远"不处理")
 |--LimitSupport.java 解决问题的具体类(解决小于指定号码的问题)
 |--OddSupport.java 解决问题的具体类(解决奇数号码的问题)
 |--SpecialSupport.java 解决问题的具体类(解决特殊号码的问题)
 步骤:建立问题类(Trouble.java)->建立解决问题的抽象类(Support.java,定义了转送字段next,设置转送字段的方法setNext和处理问题的方法support)->建立解决问题的具体类(NoSupport.java,LimitSupport.java,OddSupport.java,SpecialSupport.java,继承Support.java)->产生处理问题的对象,建立职责链

2.Command(命令)-将命令写成类
 用一个"表示命令的类的对象实例"来代表欲执行的操作,而不需采用"调用方法"的类的动态处理.如欲管理相关纪录,只需管理该对象实例的集合即可.而若预先将命令的集合存储起来,还可再执行同一命令;或者是把多个命令结合成一个新命令供再利用.
 Command Pattern 重点在于存储/使用命令
 程序示例:
 --Main.java 测试用的类
 |-command
 |    |-------Command.java 表示"命令"的接口
 |    |-------MacroCommand.java 表示"结合多个命名的命令"的类
 |
 |-drawer
      |-------DrawCommand.java 表示"点的绘制命令"的类
      |-------Drawable.java 表示"绘制对象"的接口
      |-------DrawCanvas.java 表示"绘制对象"的类
 步骤:建立命令接口(Command.java)->建立命令结合类(MacroCommand.java,将各个命令存储到一个Stack类型的字段)->建立绘制命令类(DrawCommand.java,定义绘制对象字段drawable,实现命令接口)->建立绘制对象接口(Drawable.java)->建立绘制对象类(DrawCanvas.java,实现绘制对象接口,定义命令集合字段history)->测试

3.Interpreter(解释器)-以类来表达语法规则
 Interpreter Pattern 是用简单的"迷你语言"来表现程序要解决的问题,以迷你语言写成"迷你程序"而表现具体的问题.迷你程序本身无法独自启动,必须先用java语言另外写一个负责"解释(interpreter)"的程序.解释程序能分析迷你语言,并解释\执行迷你程序.这个解释程序也称为解释器.当应解决的问题发生变化时,要修改迷你程序来对应处理.而不是修改用java语言写成的程序.
 迷你语言语法:
 <program>::=program<command list>
 <command list>::=<command>* end
 <command>::=<repeat command>|<primitive command>
 <repeat command>::=repeat<number><command list>
 <primitive command>::=go|right|left
 程序示例:
 |--Main.java 测试用的类
 |--Node.java 树状剖析中"节点"的类
 |--ProgramNode.java 对应<program>的类
 |--CommandListNode.java 对应<command list>的类
 |--CommandNode.java 对应<command>的类
 |--RepeatCommandNode.java 对应<repeat command>的类
 |--PrimitiveCommandNode.java 对应<primitive command>的类
 |--Context.java 表示语法解析之前后关系的类
 |--ParseException.java 语法解析中的例外类
 步骤:确定迷你语言的语法->建立语法解析类(Context.java,使用java.util.StringTokenizer类)->建立解析异常类(ParseException.java)->建立语法节点抽象类(Node.java,定义parse解析方法)->建立各语法节点对应的语法类(ProgramNode.java,CommandListNode.java,CommandNode.java,RepeatCommandNode.java,PrimitiveCommand.java,继承语法节点Node.java类)

4.Iterator-迭代器
 Iterator Pattern 是指依序遍历并处理多个数字或变量.
 程序示例:
 |--Main.java 测试用的类
 |--Aggregate.java 表示已聚合的类
 |--Iterator.java 执行递增\遍历的接口
 |--Book.java 表示书籍的类
 |--BookShelf.java 表示书架的类
 |--BookShelfIterator.java 扫描书架的类
 步骤:定义聚合接口(Aggregate.java)->定义遍历接口(Iterator.java)->建立具体的遍历对象类(Book.java)->建立具体的聚合类(BookShelf.java,实现聚合接口)->建立具体的遍历类(BookShelfIterator.java,实现遍历接口)

5.Mediator(中介者)-只要面对一个顾问
 每个成员都只对顾问提出报告,也只有顾问会发出指示给各个成员;成员们彼此也不会去探问目前状况如何,或乱发指示给其他成员.
 程序示例:
 |--Main.java 测试用的类
 |--Mediator.java 决定"顾问"接口(API)的接口
 |--Colleague.java 决定"成员"接口(API)的接口
 |--ColleagueButton.java 实现Colleagues接口.表示按键的类
 |--ColleagueTextField.java 实现Colleagues接口.输入文本的类
 |--ColleagueCheckbox.java 实现Colleagues接口.表示选择项目(在此为选择按钮)的类
 |--LoginFrame.java 实现Mediator接口.表示登录对话框的类
 步骤:定义顾问接口(Mediator.java)->定义成员接口(Colleague.java)->建立具体的成员类(ColleagueButton.java,ColleagueTextField.java,ColleagueCheckbox.java,实现成员接口)->建立具体的顾问类(LoginFrame.java,实现顾问接口)

6.Memento(备忘录)-存储状态
 Memento Pattern 会把某个时间点的对象实例状态记录存储起来,等到以后再让对象实例复原到当时的状态.
 程序示例:
 |--Main.java 进行游戏的类.先把Memento的对象实例存储起来,如有必要时再复原Gamer的状态
 |--game
     |-------Gamer.java 玩游戏的主人翁的类
     |-------Memento.java 表示Gamer状态的类.产生Memento的对象实例
 步骤:建立需要存储状态的类(Gamer.java)->建立状态类(Memento.java,状态类与需要存储状态的类Gamer.java应具有相同的必要字段)

7.Observer(观察者)-通知状态变化
 当被Observer Pattern 列入观察名单的状态发生变化,就会通知观察者.在写一些跟状态变化有关的处理时,Observer Pattern是很好用的工具.
 程序示例:
 |--Main.java 测试用的类
 |--Observer.java 表示观察者的接口
 |--NumberGenerator.java 表示产生数值对象的抽象类
 |--RandomNumberGenerator.java 产生随机数的类
 |--DigitObserver.java 以数字表示数值的类
 |--GraphObserver.java 以简易长条图表示数值的类
 步骤:定义观察者接口(Observer.java)->建立被观察的类(NumberGenerator.java,RandomNumberGenerator.java,定义观察者结合字段将观察者存储起来)->建立具体的观察者类(DigitObserver.java,GraphObserver.java,实现观察者接口)

8.State(状态)-以类表示状态
 以类来表示状态之后，只要切换类就能表现“状态变化”，而且在必须新增其他状态时，也很清楚该编写哪个部分。
 程序示例:
 |--Main.java 测试用的类
 |--State.java 表示金库状态的接口
 |--DayState.java 实现State的类。表示白天的状态
 |--NightState.java 实现State的类。表示夜间的状态
 |--Context.java 管理金库的状态变化，跟保安中心联络的接口
 |--SafeFrame.java 实现Context的类。含有按钮、画面显示等的用户接口
 步骤:定义状态接口(State.java,将使用State Pattern之前各种行为方法抽象出来)->建立具体的状态类(DayState.java,NightState.java,实现状态接口,状态变化的具体动作在这里执行)->定义管理状态变化的接口(Context.java,规定状态变化及相关的调用方法)->建立状态管理类(SafeFrame.java,实现状态管理接口)

9.Strategy(策略)-把算法整个换掉
 在Strategy Pattern之下，可以更换实现算法的部分而且不留痕迹。切换整个算法，简化改为采用其他方法来解决同样的问题。
 程序示例:
 |--Main.java 测试用的类
 |--Hand.java 表示猜拳“手势”的类
 |--Strategy.java 表示猜拳“战略”的接口
 |--WinningStrategy.java 表示猜赢之后继续出同样招式的战略的类
 |--ProbStrategy.java 表示从上一次出的招式，以概率分配方式求出下一个招式机率的类
 |--Player.java 表示玩猜拳的游戏者的类
 步骤:定义策略接口(Strategy.java)->建立具体的策略类(WinningStrategy.java,ProbStrategy.java,实现策略接口)->建立使用策略的类(Player.java,定义策略字段，以便使用切换策略)->建立其它类(Main.java,Hand.java)

10.Template Method(模板方法)-实际处理交给子类
 在父类指定处理大纲、在子类规定具体内容的Design Pattern就称为Template Method Pattern
 程序示例:
 |--Main.java 测试用的类
 |--AbstractDisplay.java 只实现方法display的抽象类
 |--CharDisplay.java 实现方法open,print,close的类
 |--StringDisplay.java 实现方法open,print,close的类
 步骤:定义模板类(AbstractDisplay.java,实现dispaly方法，即制作了模板)->建立具体内容类(CharDisplay.java,StringDisplay.java,继承模板类，实现模板类没有实现的方法)

11.Visitor(访问者)-在结构中穿梭还同时做事
 Visitor Pattern 把数据结构和处理两者分开，另外写一个表示在数据结构内穿梭来去的主体“访客”的类，然后把处理交给这个类来进行。如此一来，如果想追加新的处理行为时，只要再建立一个新的“访客”即可。而在数据结构这边，也只要能接受来敲门的“访客”就能完成动作。
 在父类指定处理大纲、在子类规定具体内容的Design Pattern就称为Template Method Pattern
 程序示例:
 |--Main.java 测试用的类
 |--Visitor.java 表示访问文件或目录的访客的抽象类
 |--Acceptor.java 表示接受Visitor类的对象实例的数据结构的接口
 |--ListVisitor.java Visitor类的子类，打印文件和目录信息的类
 |--Entry.java File和Directory的父类的抽象类(实现Acceptor接口)
 |--File.java 表示文件的类
 |--Directory.java 表示目录的类
 |--FileTreatmentException.java 发生在对File进行add时的例外类
 步骤:定义访问者的抽象类(Visitor.java,定义访问方法)->定义受访者接口(Acceptor.java,定义接受访问的方法)->建立具体的访问者类(ListVisitor.java,继承访问者抽象类，实现访问方法)->建立具体的受访者类(Entry.java,File.java,Directory.java,实现受访者接口)->编写异常类(FileTreatmentException.java)

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/pian_yun/archive/2007/09/14/1784981.aspx

　　1，位移运算越界怎么处理

　　考察下面的代码输出结果是多少?

　　int a=5;

　　System.out.println(a < <33);

　　按照常理推测,把a左移33位应该将a的所有有效位都移出去了，那剩下的都是零啊，所以输出结果应该是0才对啊，可是执行后发现输出结果是10，为什么呢？因为Java语言对位移运算作了优化处理，Java语言对a < <b转化为a < <(b%32)来处理，所以当要移位的位数b超过32时，实际上移位的位数是b%32的值，那么上面的代码中a < <33相当于a < <1，所以输出结果是10。

　　2，可以让i!=i吗？

　　当你看到这个命题的时候一定会以为我疯了，或者Java语言疯了。这看起来是绝对不可能的，一个数怎么可能不等于它自己呢？或许就真的是Java语言疯了，不信看下面的代码输出什么？

　　double i=0.0/0.0;

　　if(i==i){

　　System.out.println("Yes i==i");

　　}else{

　　System.out.println("No i!=i");

　　}

　　上面的代码输出"No i!=i"，为什么会这样呢？关键在0.0/0.0这个值，在IEEE 754浮点算术规则里保留了一个特殊的值用来表示一个不是数字的数量。这个值就是NaN("Not a Number"的缩写)，对于所有没有良好定义的浮点计算都将得到这个值，比如：0.0/0.0；其实我们还可以直接使用Double.NaN来得到这个值。在IEEE 754规范里面规定NaN不等于任何值，包括它自己。所以就有了i！=i的代码。

　　3，怎样的equals才安全？

　　我们都知道在Java规范里定义了equals方法覆盖的5大原则：reflexive（反身性），symmetric（对称性），transitive（传递性），consistent（一致性），non-null（非空性）。那么考察下面的代码：

　　public class Student{

　　private String name;

　　private int age;

　　public Student(String name,int age){

　　this.name=name;

　　this.age=age;

　　}

　　public boolean equals(Object obj){

　　if(obj instanceof Student){

　　Student s=(Student)obj;

　　if(s.name.equals(this.name) && s.age==this.age){

　　return true;

　　}

　　}

　　return super.equals(obj);

　　}

　　}

　　你认为上面的代码equals方法的覆盖安全吗？表面看起来好像没什么问题，这样写也确实满足了以上的五大原则。但其实这样的覆盖并不很安全，假如Student类还有一个子类CollegeStudent,如果我拿一个Student对象和一个CollegeStudent对象equals,只要这两个对象有相同的name和age，它们就会被认为相等，但实际上它们是两个不同类型的对象啊。问题就出在instanceof这个运算符上，因为这个运算符是向下兼容的，也就是说一个CollegeStudent对象也被认为是一个Student的实例。怎样去解决这个问题呢？那就只有不用instanceof运算符，而使用对象的getClass()方法来判断两个对象是否属于同一种类型，例如，将上面的equals()方法修改为：

　　public boolean equals(Object obj){

　　if(obj.getClass()==Student.class){

　　Student s=(Student)obj;

　　if(s.name.equals(this.name) && s.age==this.age){

　　return true;

　　}

　　}

　　return super.equals(obj);

　　}

　　这样才能保证obj对象一定是Student的实例，而不会是Student的任何子类的实例。

　　1）浅复制与深复制概念

　　⑴浅复制（浅克隆）

　　被复制对象的所有变量都含有与原来的对象相同的值，而所有的对其他对象的引用仍然指向原来的对象。换言之，浅复制仅仅复制所考虑的对象，而不复制它所引用的对象。

　　⑵深复制（深克隆）

　　被复制对象的所有变量都含有与原来的对象相同的值，除去那些引用其他对象的变量。那些引用其他对象的变量将指向被复制过的新对象，而不再是原有的那些被引用的对象。换言之，深复制把要复制的对象所引用的对象都复制了一遍。

　　2）Java的clone（）方法

　　⑴clone方法将对象复制了一份并返回给调用者。一般而言，clone（）方法满足：

　　①对任何的对象x，都有x.clone() !=x//克隆对象与原对象不是同一个对象

　　②对任何的对象x，都有x.clone().getClass()= =x.getClass()//克隆对象与原对象的类型一样

　　③如果对象x的equals()方法定义恰当，那么x.clone().equals(x)应该成立。

　　⑵Java中对象的克隆

　　①为了获取对象的一份拷贝，我们可以利用Object类的clone()方法。

　　②在派生类中覆盖基类的clone()方法，并声明为public。

　　③在派生类的clone()方法中，调用super.clone()。

　　④在派生类中实现Cloneable接口。

　　请看如下代码：

　　class Student implements Cloneable{

　　String name;

　　int age;

　　Student(String name,int age){

　　this.name=name;

　　this.age=age;

　　}

　　public Object clone(){

　　Object obj=null;

　　try{

　　obj=(Student)super.clone();

　　//Object中的clone()识别出你要复制的是哪一个对象。

　　}

　　catch(CloneNotSupportedException e){

　　e.printStackTrace();

　　}

　　return obj;

　　}

　　}

　　public static void main(String[] args){

　　Student s1=new Student("zhangsan",18);

　　Student s2=(Student)s1.clone();

　　s2.name="lisi";

　　s2.age=20;

　　System.out.println("name="+s1.name+","+"age="+s1.age);//修改学生2

　　//后，不影响学生1的值。

　　}

　　说明：

　　①为什么我们在派生类中覆盖Object的clone()方法时，一定要调用super.clone()呢？在运行时刻，Object中的clone()识别出你要复制的是哪一个对象，然后为此对象分配空间，并进行对象的复制，将原始对象的内容一一复制到新对象的存储空间中。

　　②继承自java.lang.Object类的clone()方法是浅复制。以下代码可以证明之。

　　class Teacher{

　　String name;

　　int age;

　　Teacher(String name,int age){

　　this.name=name;

　　this.age=age;

　　}

　　}

　　class Student implements Cloneable{

　　String name;

　　int age;

　　Teacher t;//学生1和学生2的引用值都是一样的。

　　Student(String name,int age,Teacher t){

　　this.name=name;

　　this.age=age;

　　this.t=t;

　　}

　　Student stu=null;

　　try{

　　stu=(Student)super.clone();

　　}catch(CloneNotSupportedException e){

　　e.printStackTrace();

　　}

　　stu.t=(Teacher)t.clone();

　　return stu;

　　}

　　public static void main(String[] args){

　　Teacher t=new Teacher("tangliang",30);

　　Student s1=new Student("zhangsan",18,t);

　　Student s2=(Student)s1.clone();

　　s2.t.name="tony";

　　s2.t.age=40;

　　System.out.println("name="+s1.t.name+","+"age="+s1.t.age);

　　//学生1的老师成为tony,age为40。

　　}

　　}

　　那应该如何实现深层次的克隆，即修改s2的老师不会影响s1的老师？代码改进如下。

　　class Teacher implements Cloneable{

　　String name;

　　int age;

　　Teacher(String name,int age){

　　this.name=name;

　　this.age=age;

　　}

　　public Object clone(){

　　Object obj=null;

　　try{

　　obj=super.clone();

　　}catch(CloneNotSupportedException e){

　　e.printStackTrace();

　　}

　　return obj;

　　}

　　}

　　class Student implements Cloneable{

　　String name;

　　int age;

　　Teacher t;

　　Student(String name,int age,Teacher t){

　　this.name=name;

　　this.age=age;

　　this.t=t;

　　}

　　public Object clone(){

　　Student stu=null;

　　try{

　　stu=(Student)super.clone();

　　}catch(CloneNotSupportedException e){

　　e.printStackTrace();

　　}

　　stu.t=(Teacher)t.clone();

　　return stu;

　　}

　　}

　　public static void main(String[] args){

　　Teacher t=new Teacher("tangliang",30);

　　Student s1=new Student("zhangsan",18,t);

　　Student s2=(Student)s1.clone();

　　s2.t.name="tony";

　　s2.t.age=40;

　　System.out.println("name="+s1.t.name+","+"age="+s1.t.age);

　　//学生1的老师不改变。

　　}

　　把对象写到流里的过程是串行化（Serilization）过程，Java程序员又非常形象地称为“冷冻”或者“腌咸菜（picking）”过程；而把对象从流中读出来的并行化（Deserialization）过程则叫做“解冻”或者“回鲜(depicking)”过程。应当指出的是，写在流里的是对象的一个拷贝，而原对象仍然存在于JVM里面，因此“腌成咸菜”的只是对象的一个拷贝，Java咸菜还可以回鲜。

　　在Java语言里深复制一个对象，常常可以先使对象实现Serializable接口，然后把对象（实际上只是对象的一个拷贝）写到一个流里（腌成咸菜），再从流里读出来（把咸菜回鲜），便可以重建对象。

　　如下为深复制源代码。

　　public Object deepClone(){

　　//将对象写到流里

　　ByteArrayOutoutStream bo=new ByteArrayOutputStream();

　　ObjectOutputStream oo=new ObjectOutputStream(bo);

　　oo.writeObject(this);

　　//从流里读出来

　　ByteArrayInputStream bi=new ByteArrayInputStream(bo.toByteArray());

　　ObjectInputStream oi=new ObjectInputStream(bi);

　　return(oi.readObject());

　　}

　　这样做的前提是对象以及对象内部所有引用到的对象都是可串行化的，否则，就需要仔细考察那些不可串行化的对象可否设成transient，从而将之排除在复制过程之外。上例代码改进如下。

　　class Teacher implements Serializable{

　　String name;

　　int age;

　　Teacher(String name,int age){

　　this.name=name;

　　this.age=age;

　　}

　　}

　　class Student implements Serializable

　　{

　　String name;//常量对象。

　　int age;

　　Teacher t;//学生1和学生2的引用值都是一样的。

　　Student(String name,int age,Teacher t){

　　this.name=name;

　　this.age=age;

　　this.p=p;

　　}

　　public Object deepClone() throws IOException,

　　OptionalDataException,ClassNotFoundException

　　{

　　//将对象写到流里

　　ByteArrayOutoutStream bo=new ByteArrayOutputStream();

　　ObjectOutputStream oo=new ObjectOutputStream(bo);

　　oo.writeObject(this);

　　//从流里读出来

　　ByteArrayInputStream bi=new ByteArrayInputStream(bo.toByteArray());

　　ObjectInputStream oi=new ObjectInputStream(bi);

　　return(oi.readObject());

　　}

　　}

　　public static void main(String[] args){

　　Teacher t=new Teacher("tangliang",30);

　　Student s1=new Student("zhangsan",18,t);

　　Student s2=(Student)s1.deepClone();

　　s2.t.name="tony";

　　s2.t.age=40;

　　System.out.println("name="+s1.t.name+","+"age="+s1.t.age);

　　//学生1的老师不改变。

　　}

　　在一些高性能的数据操作中，越高级的框架越不适合使用。这里是我在开发中对JDBC使用过程中一些优化经验总结。

　　1、选择纯Java的JDBC驱动。

　　2、使用连接池--使用一个“池”来管理JDBC连接，并精心调试池配置的参数，目前可用的数据库连接池很多很多。

　　如何配置合适的参数呢，需要的是测试，而不是感觉。

　　3、重用Connection--最大限度使用每个数据库连接，得到了就不要轻易“丢弃”。

　　有时候在一个过程中，会多次操作数据库，而仅仅需要一个连接就够了，没必用一次就获取一个连接，用完后关闭或者入池。这样会增加“池”管理的成本，千万别以为你用了“池”就可以随便申请和归还连接，都是有代价的。如果是一个庞大循环块中操作数据库，更应该注意此问题！

　　4、重用Statement--对于一些预定义SQL，设置为静态常量，并尽可能重用预定义SQL产生的PreparedStatement对象。对于多次使用一种模式的SQL，使用预定义SQL可以获取更好的性能。

　　5、使用批处理SQL。

　　6、优化结果集ResultSet--查询时候，返回的结果集有不同的类型，优先选择只读结果集、不可滚动的属性。

　　这里是很容易出现问题的地方：

　　结果集分两种类型：只读和可更改，只读的话，更省内存，查询的结果集不能更改。如果结果集在查询后，更改了值又要保存，则使用可更改结果集。

　　结果集的游标也有两种类型：如果没必要让游标自由滚动，则选择单方向移动的游标类型。

　　对于是否并发操作：如果不需要考虑线程安全，则选择忽略并发的结果集类型，否则选择并发安全的类型。

　　另外，还要控制结果的大小，几乎所有的数据库都有查询记录条数控制的策略，可以海量数据进行分批处理，一次一批，这样不至于把系统搞死。

　　7、事物优化--如果数据库不支持事物，就不要写回滚代码，如果不考虑事物，就不要做事务的控制。

　　8、安全优化--管理好你的Connection对象，在异常时候能“入池”或者关闭。因此应该将Connection释放的代码写在异常处理的finally块中。

　　9、异常处理优化--不要轻易吞噬SQLException，对于DAO、Service层次的数据访问，一般在DAO中跑出异常，在Service中处理异常。但DAO中也可以处理异常，并做转义抛出，不要随便抛出RuntimeExeption，因为这是JVM抛出的，不需要你可以去抛出，因为RuntimeException往往会导致系统挂起。

　　10、代码高层优化--在以上的基础上，优化封装你的数据访问方式，尽可能让代码简洁好维护，如果你还觉得性能不行，那就该从整个系统角度考虑优化了，比如加上缓存服务器，集群、负载均衡、优化数据库服务器等等，以获取更好的系能。

　　本文出自 “熔 岩” 博客，请务必保留此出处http://lavasoft.blog.51cto.com/62575/225828

    在函数中定义的一些基本类型的变量和对象的引用变量都在函数的栈内存中分配。

    当在一段代码块定义一个变量时，Java就在栈中为这个变量分配内存空间，当超过变量的作用域后，Java会自动释放掉为该变量所分配的内存空间，该内存空间可以立即被另作他用。

    堆内存用来存放由new创建的对象和数组。

    在堆中分配的内存，由Java虚拟机的自动垃圾回收器来管理。

    在堆中产生了一个数组或对象后，还可以在栈中定义一个特殊的变量，让栈中这个变量的取值等于数组或对象在堆内存中的首地址，栈中的这个变量就成了数组或对象的引用变量。

    引用变量就相当于是为数组或对象起的一个名称，以后就可以在程序中使用栈中的引用变量来访问堆中的数组或对象。

    具体的说：

    栈与堆都是Java用来在Ram中存放数据的地方。与C++不同，Java自动管理栈和堆，程序员不能直接地设置栈或堆。

    Java的堆是一个运行时数据区,类的(对象从中分配空间。这些对象通过new、newarray、anewarray和multianewarray等 指令建立，它们不需要程序代码来显式的释放。堆是由垃圾回收来负责的，堆的优势是可以动态地分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时 动态分配内存的，Java的垃圾收集器会自动收走这些不再使用的数据。但缺点是，由于要在运行时动态分配内存，存取速度较慢。

    栈的优势是，存取速度比堆要快，仅次于寄存器，栈数据可以共享。但缺点是，存在栈中的数据大小与生存期必须是确定的，缺乏灵活性。栈中主要存放一些基本 类型的变量（,int, short, long, byte, float, double, boolean, char）和对象句柄。

    栈有一个很重要的特殊性，就是存在栈中的数据可以共享。假设我们同时定义：

    int a = 3;

    int b = 3；

    编译器先处理int a = 3；首先它会在栈中创建一个变量为a的引用，然后查找栈中是否有3这个值，如果没找到，就将3存放进来，然后将a指向3。接着处理int b = 3；在创建完b的引用变量后，因为在栈中已经有3这个值，便将b直接指向3。这样，就出现了a与b同时均指向3的情况。这时，如果再令a=4；那么编译器 会重新搜索栈中是否有4值，如果没有，则将4存放进来，并令a指向4；如果已经有了，则直接将a指向这个地址。因此a值的改变不会影响到b的值。要注意这 种数据的共享与两个对象的引用同时指向一个对象的这种共享是不同的，因为这种情况a的修改并不会影响到b, 它是由编译器完成的，它有利于节省空间。而一个对象引用变量修改了这个对象的内部状态，会影响到另一个对象引用变量。

    String是一个特殊的包装类数据。可以用：

    String str = new String("abc");

    String str = "abc";

    两种的形式来创建，第一种是用new()来新建对象的，它会在存放于堆中。每调用一次就会创建一个新的对象。

    而第二种是先在栈中创建一个对String类的对象引用变量str，然后查找栈中有没有存放"abc"，如果没有，则将"abc"存放进栈，并令str指向“abc”，如果已经有“abc” 则直接令str指向“abc”。

    比较类里面的数值是否相等时，用equals()方法；当测试两个包装类的引用是否指向同一个对象时，用==，下面用例子说明上面的理论。

    String str1 = "abc";

    String str2 = "abc";

    System.out.println(str1==str2); //true可以看出str1和str2是指向同一个对象的。

    String str1 =new String ("abc");

    String str2 =new String ("abc");

    System.out.println(str1==str2); // false用new的方式是生成不同的对象。每一次生成一个。

    因此用第二种方式创建多个“abc”字符串,在内存中其实只存在一个对象而已. 这种写法有利与节省内存空间. 同时它可以在一定程度上提高程序的运行速度，因为JVM会自动根据栈中数据的实际情况来决定是否有必要创建新对象。而对于String str = new String("abc")；的代码，则一概在堆中创建新对象，而不管其字符串值是否相等，是否有必要创建新对象，从而加重了程序的负担。

    另一方面, 要注意: 我们在使用诸如String str = "abc"；的格式定义类时，总是想当然地认为，创建了String类的对象str。担心陷阱！对象可能并没有被创建！而可能只是指向一个先前已经创建的 对象。只有通过new()方法才能保证每次都创建一个新的对象。 由于String类的immutable性质，当String变量需要经常变换其值时，应该考虑使用StringBuffer类，以提高程序效率。

    java中内存分配策略及堆和栈的比较

    2.1 内存分配策略按照编译原理的观点,程序运行时的内存分配有三种策略,分别是静态的,栈式的,和堆式的.静态存储分配是指在编译时就能确定每个数据目标在运行时刻的存储空间需求,因而在编译时就可以给他们分配固定的内存空间.这种分配策略要求程序代码中不允 许有可变数据结构(比如可变数组)的存在,也不允许有嵌套或者递归的结构出现,因为它们都会导致编译程序无法计算准确的存储空间需求.栈式存储分配也可称为动态存储分配,是由一个类似于堆栈的运行栈来实现的.和静态存储分配相反,在栈式存储方案中,程序对数据区的需求在编译时是完全未知 的,只有到运行的时候才能够知道,但是规定在运行中进入一个程序模块时,必须知道该程序模块所需的数据区大小才能够为其分配内存.和我们在数据结构所熟知 的栈一样,栈式存储分配按照先进后出的原则进行分配。

    静态存储分配要求在编译时能知道所有变量的存储要求,栈式存储分配要求在过程的入口处必须知道所有的存储要求,而堆式存储分配则专门负责在编译时或运行时 模块入口处都无法确定存储要求的数据结构的内存分配,比如可变长度串和对象实例.堆由大片的可利用块或空闲块组成,堆中的内存可以按照任意顺序分配和释 放.

    2.2 堆和栈的比较

    上面的定义从编译原理的教材中总结而来,除静态存储分配之外,都显得很呆板和难以理解,下面撇开静态存储分配,集中比较堆和栈:从堆和栈的功能和作用来通俗的比较,堆主要用来存放对象的，栈主要是用来执行程序的.而这种不同又主要是由于堆和栈的特点决定的:在编程中，例如C/C++中，所有的方法调用都是通过栈来进行的,所有的局部变量,形式参数都是从栈中分配内存空间的。实际上也不是什么分配,只是从栈顶 向上用就行,就好像工厂中的传送带(conveyor belt)一样,Stack Pointer会自动指引你到放东西的位置,你所要做的只是把东西放下来就行.退出函数的时候，修改栈指针就可以把栈中的内容销毁.这样的模式速度最快, 当然要用来运行程序了.需要注意的是,在分配的时候,比如为一个即将要调用的程序模块分配数据区时,应事先知道这个数据区的大小,也就说是虽然分配是在程 序运行时进行的,但是分配的大小多少是确定的,不变的,而这个"大小多少"是在编译时确定的,不是在运行时.堆是应用程序在运行的时候请求操作系统分配给自己内存，由于从操作系统管理的内存分配,所以在分配和销毁时都要占用时间，因此用堆的效率非常低.但是堆的 优点在于,编译器不必知道要从堆里分配多少存储空间，也不必知道存储的数据要在堆里停留多长的时间,因此,用堆保存数据时会得到更大的灵活性。事实上,面 向对象的多态性,堆内存分配是必不可少的,因为多态变量所需的存储空间只有在运行时创建了对象之后才能确定.在C++中，要求创建一个对象时，只需用 new命令编制相关的代码即可。执行这些代码时，会在堆里自动进行数据的保存.当然，为达到这种灵活性，必然会付出一定的代价:在堆里分配存储空间时会花 掉更长的时间！这也正是导致我们刚才所说的效率低的原因,看来列宁同志说的好,人的优点往往也是人的缺点,人的缺点往往也是人的优点.

    2.3 JVM中的堆和栈JVM是基于堆栈的虚拟机.JVM为每个新创建的线程都分配一个堆栈.也就是说,对于一个Java程序来说，它的运行就是通过对堆栈的操作来完成的。堆栈以帧为单位保存线程的状态。JVM对堆栈只进行两种操作:以帧为单位的压栈和出栈操作。

    我们知道,某个线程正在执行的方法称为此线程的当前方法.我们可能不知道,当前方法使用的帧称为当前帧。当线程激活一个Java方法,JVM就会在线程的 Java堆栈里新压入一个帧。这个帧自然成为了当前帧.在此方法执行期间,这个帧将用来保存参数,局部变量,中间计算过程和其他数据.这个帧在这里和编译 原理中的活动纪录的概念是差不多的.从Java的这种分配机制来看,堆栈又可以这样理解:堆栈(Stack)是操作系统在建立某个进程时或者线程(在支持多线程的操作系统中是线程)为这个线程建立的存储区域，该区域具有先进后出的特性。

    每一个Java应用都唯一对应一个JVM实例，每一个实例唯一对应一个堆。应用程序在运行中所创建的所有类实例或数组都放在这个堆中,并由应用所有的线程 共享.跟C/C++不同，Java中分配堆内存是自动初始化的。Java中所有对象的存储空间都是在堆中分配的，但是这个对象的引用却是在堆栈中分配,也 就是说在建立一个对象时从两个地方都分配内存，在堆中分配的内存实际建立这个对象，而在堆栈中分配的内存只是一个指向这个堆对象的指针(引用)而已。

    Java nio 2.0的主要改进就是引入了异步IO（包括文件和网络），这里主要介绍下异步网络IO API的使用以及框架的设计，以TCP服务端为例。首先看下为了支持AIO引入的新的类和接口：

    java.nio.channels.AsynchronousChannel标记一个channel支持异步IO操作。

    java.nio.channels.AsynchronousServerSocketChannel ServerSocket的aio版本，创建TCP服务端，绑定地址，监听端口等。

    java.nio.channels.AsynchronousSocketChannel面向流的异步socket channel，表示一个连接。

    java.nio.channels.AsynchronousChannelGroup异步channel的分组管理，目的是为了资源共享。一个AsynchronousChannelGroup绑定一个线程池，这个线程池执行两个任务：处理IO事件和派发CompletionHandler.AsynchronousServerSocketChannel创建的时候可以传入一个AsynchronousChannelGroup，那么通过AsynchronousServerSocketChannel创建的AsynchronousSocketChannel将同属于一个组，共享资源。

    java.nio.channels.CompletionHandler异步IO操作结果的回调接口，用于定义在IO操作完成后所作的回调工作。AIO的API允许两种方式来处理异步操作的结果：返回的Future模式或者注册CompletionHandler，我更推荐用CompletionHandler的方式，这些handler的调用是由AsynchronousChannelGroup的线程池派发的。显然，线程池的大小是性能的关键因素。AsynchronousChannelGroup允许绑定不同的线程池，通过三个静态方法来创建：public static AsynchronousChannelGroup withFixedThreadPool（int nThreads，

    ThreadFactory threadFactory）

    throws IOException

    public static AsynchronousChannelGroup withCachedThreadPool（ExecutorService executor，

    int initialSize）

    public static AsynchronousChannelGroup withThreadPool（ExecutorService executor）

    throws IOException

    需要根据具体应用相应调整，从框架角度出发，需要暴露这样的配置选项给用户。

    在介绍完了aio引入的TCP的主要接口和类之后，我们来设想下一个aio框架应该怎么设计。参考非阻塞nio框架的设计，一般都是采用Reactor模式，Reacot负责事件的注册、select、事件的派发；相应地，异步IO有个Proactor模式，Proactor负责CompletionHandler的派发，查看一个典型的IO写操作的流程来看两者的区别：

    Reactor：  send（msg） -> 消息队列是否为空，如果为空  -> 向Reactor注册OP_WRITE，然后返回 -> Reactor select -> 触发Writable，通知用户线程去处理 ->先注销Writable（很多人遇到的cpu 100%的问题就在于没有注销），处理Writeable，如果没有完全写入，继续注册OP_WRITE.注意到，写入的工作还是用户线程在处理。

    Proactor： send（msg） -> 消息队列是否为空，如果为空，发起read异步调用，并注册CompletionHandler，然后返回。 -> 操作系统负责将你的消息写入，并返回结果（写入的字节数）给Proactor -> Proactor派发CompletionHandler.可见，写入的工作是操作系统在处理，无需用户线程参与。事实上在aio的API中，AsynchronousChannelGroup就扮演了Proactor的角色。

    CompletionHandler有三个方法，分别对应于处理成功、失败、被取消（通过返回的Future）情况下的回调处理：

    public interface CompletionHandler {

    void completed（V result， A attachment）；

    void failed（Throwable exc， A attachment）；

    void cancelled（A attachment）；

    }

    其中的泛型参数V表示IO调用的结果，而A是发起调用时传入的attchment.

    在初步介绍完aio引入的类和接口后，我们看看一个典型的tcp服务端是怎么启动的，怎么接受连接并处理读和写，这里引用的代码都是yanf4j 的aio分支中的代码，可以从svn checkout，svn地址： http://yanf4j.googlecode.com/svn/branches/yanf4j-aio

    第一步，创建一个AsynchronousServerSocketChannel，创建之前先创建一个AsynchronousChannelGroup，上文提到AsynchronousServerSocketChannel可以绑定一个AsynchronousChannelGroup，那么通过这个AsynchronousServerSocketChannel建立的连接都将同属于一个AsynchronousChannelGroup并共享资源：this.asynchronousChannelGroup = AsynchronousChannelGroup。withCachedThreadPool（Executors.newCachedThreadPool（），this.threadPoolSize）；然后初始化一个AsynchronousServerSocketChannel，通过open方法：this.serverSocketChannel = AsynchronousServerSocketChannel。open（this.asynchronousChannelGroup）；通过nio 2.0引入的SocketOption类设置一些TCP选项：this.serverSocketChannel。setOption（StandardSocketOption.SO_REUSEADDR，true）；this.serverSocketChannel。setOption（StandardSocketOption.SO_RCVBUF，16*1024）；

    绑定本地地址：

    this.serverSocketChannel。bind（new InetSocketAddress（"localhost"，8080）， 100）；其中的100用于指定等待连接的队列大小（backlog）。完了吗？还没有，最重要的监听工作还没开始，监听端口是为了等待连接上来以便accept产生一个AsynchronousSocketChannel来表示一个新建立的连接，因此需要发起一个accept调用，调用是异步的，操作系统将在连接建立后，将最后的结果——AsynchronousSocketChannel返回给你：

    public void pendingAccept（）{

    if （this.started  this.serverSocketChannel.isOpen（）） { this.acceptFuture = this.serverSocketChannel.accept（null，

    new AcceptCompletionHandler（））；

    } else {

    throw new IllegalStateException（"Controller has been closed"）；

    }

    注意，重复的accept调用将会抛出PendingAcceptException，后文提到的read和write也是如此。accept方法的第一个参数是你想传给CompletionHandler的attchment，第二个参数就是注册的用于回调的CompletionHandler，最后返回结果Future.你可以对future做处理，这里采用更推荐的方式就是注册一个CompletionHandler.那么accept的CompletionHandler中做些什么工作呢？显然一个赤裸裸的AsynchronousSocketChannel是不够的，我们需要将它封装成session，一个session表示一个连接（mina里就叫IoSession了），里面带了一个缓冲的消息队列以及一些其他资源等。在连接建立后，除非你的服务器只准备接受一个连接，不然你需要在后面继续调用pendingAccept来发起另一个accept请求：

    private final class AcceptCompletionHandler implements

    CompletionHandler {

    @Override

    public void cancelled（Object attachment）{

    logger.warn（"Accept operation was canceled"）；

    }

    public void completed（AsynchronousSocketChannel socketChannel，

    Object attachment）{

    try {

    logger.debug（"Accept connection from " + socketChannel.getRemoteAddress（））；

    configureChannel（socketChannel）；

    AioSessionConfig sessionConfig = buildSessionConfig（socketChannel）；

    Session session = new AioTCPSession（sessionConfig，AioTCPController.this.configuration。getSessionReadBufferSize（），AioTCPController.this.sessionTimeout）；session.start（）；

    registerSession（session）；

    } catch（Exception e）{

    e.printStackTrace（）；logger.error（"Accept error"， e）；

    notifyException（e）；

    } finally {

    pendingAccept（）；

    }

    @Override

    public void failed（Throwable exc， Object attachment） { logger.error（"Accept error"， exc）；

    try {

    notifyException（exc）；

    } finally {

    pendingAccept（）；

    }

    注意到了吧，我们在failed和completed方法中在最后都调用了pendingAccept来继续发起accept调用，等待新的连接上来。有的同学可能要说了，这样搞是不是递归调用，会不会堆栈溢出？实际上不会，因为发起accept调用的线程与CompletionHandler回调的线程并非同一个，不是一个上下文中，两者之间没有耦合关系。要注意到，CompletionHandler的回调共用的是AsynchronousChannelGroup绑定的线程池，因此千万别在回调方法中调用阻塞或者长时间的操作，例如sleep，回调方法最好能支持超时，防止线程池耗尽。

    连接建立后，怎么读和写呢？回忆下在nonblocking nio框架中，连接建立后的第一件事是干什么？注册OP_READ事件等待socket可读。异步IO也同样如此，连接建立后马上发起一个异步read调用，等待socket可读，这个是Session.start方法中所做的事情：

    public class AioTCPSession {

    protected void start0（）{

    pendingRead（）；

    }

    protected final void pendingRead（）{

    if （！isClosed（）  this.asynchronousSocketChannel.isOpen（）） { if （！this.readBuffer.hasRemaining（）） { this.readBuffer = ByteBufferUtils。increaseBufferCapatity（this.readBuffer）；

    }

    this.readFuture = this.asynchronousSocketChannel.read（this.readBuffer， this， this.readCompletionHandler）；

    } else {

    throw new IllegalStateException（

    "Session Or Channel has been closed"）；

    }

    }

    AsynchronousSocketChannel的read调用与AsynchronousServerSocketChannel的accept调用类似，同样是非阻塞的，返回结果也是一个Future，但是写的结果是整数，表示写入了多少字节，因此read调用返回的是Future，方法的第一个参数是读的缓冲区，操作系统将IO读到数据拷贝到这个缓冲区，第二个参数是传递给CompletionHandler的attchment，第三个参数就是注册的用于回调的CompletionHandler.这里保存了read的结果Future，这是为了在关闭连接的时候能够主动取消调用，accept也是如此。现在可以看看read的CompletionHandler的实现：

    public final class ReadCompletionHandler implements

    CompletionHandler {

    private static final Logger log = LoggerFactory

    。getLogger（ReadCompletionHandler.class）；

    protected final AioTCPController controller；

    public ReadCompletionHandler（AioTCPController controller）{

    this.controller = controller；

    }

    @Override

    public void cancelled（AbstractAioSession session）{

    log.warn（"Session（" + session.getRemoteSocketAddress（）

    + "）read operation was canceled"）；

    }

    @Override

    public void completed（Integer result， AbstractAioSession session） { if （log.isDebugEnabled（））

    log.debug（"Session（" + session.getRemoteSocketAddress（）

    + "）read +" + result + " bytes"）；

    if（result 0）{

    session.updateTimeStamp（）；session.getReadBuffer（）。flip（）；session.decode（）；session.getReadBuffer（）。compact（）；

    }

    } finally {

    try {

    session.pendingRead（）；

    } catch（IOException e）{

    session.onException（e）；session.close（）；

    }

    controller.checkSessionTimeout（）；

    }

    @Override

    public void failed（Throwable exc， AbstractAioSession session） { log.error（"Session read error"， exc）；session.onException（exc）；session.close（）；

    }

    }

    }

    this.asynchronousSocketChannel.close（）；   在读成功的情况下，我们还需要判断结果result是否小于0，如果小于0就表示对端关闭了，这种情况下我们也主动关闭连接并返回。如果读到一定字节，也就是result大于0的情况下，我们就尝试从读缓冲区中decode出消息，并派发给业务处理器的回调方法，最终通过pendingRead继续发起read调用等待socket的下一次可读。可见，我们并不需要自己去调用channel来进行IO读，而是操作系统帮你直接读到了缓冲区，然后给你一个结果表示读入了多少字节，你处理这个结果即可。而nonblocking IO框架中，是reactor通知用户线程socket可读了，然后用户线程自己去调用read进行实际读操作。这里还有个需要注意的地方，就是decode出来的消息的派发给业务处理器工作最好交给一个线程池来处理，避免阻塞group绑定的线程池。

    IO写的操作与此类似，不过通常写的话我们会在session中关联一个缓冲队列来处理，没有完全写入或者等待写入的消息都存放在队列中，队列为空的情况下发起write调用：

    protected void write0（WriteMessage message）{

    boolean needWrite = false；

    synchronized （this.writeQueue） { needWrite = this.writeQueue.isEmpty（）；this.writeQueue.offer（message）；

    }

    if（needWrite）{

    pendingWrite（message）；

    }

    protected final void pendingWrite（WriteMessage message）{

    message = preprocessWriteMessage（message）；

    if （！isClosed（）  this.asynchronousSocketChannel.isOpen（）） { this.asynchronousSocketChannel.write（message.getWriteBuffer（），this， this.writeCompletionHandler）；

    } else {

    throw new IllegalStateException（

    "Session Or Channel has been closed"）；

    }

    write调用返回的结果与read一样是一个Future，而write的CompletionHandler处理的核心逻辑大概是这样：

    @Override

    public void completed（Integer result， AbstractAioSession session） { if （log.isDebugEnabled（））

    log.debug（"Session（" + session.getRemoteSocketAddress（）

    + "）writen " + result + " bytes"）；

    WriteMessage writeMessage；

    Queue writeQueue = session.getWriteQueue（）；

    synchronized（writeQueue）{

    writeMessage = writeQueue.peek（）；if （writeMessage.getWriteBuffer（） == null || ！writeMessage.getWriteBuffer（）。hasRemaining（）） { writeQueue.remove（）；if （writeMessage.getWriteFuture（） ！= null） { writeMessage.getWriteFuture（）。setResult（Boolean.TRUE）；

    }

    try {

    session.getHandler（）。onMessageSent（session，writeMessage.getMessage（））；

    } catch（Exception e）{

    session.onException（e）；

    }

    writeMessage = writeQueue.peek（）；

    }

    if （writeMessage ！= null） {

    try {

    session.pendingWrite（writeMessage）；

    } catch（IOException e）{

    session.onException（e）；session.close（）；

    }

    compete方法中的result就是实际写入的字节数，然后我们判断消息的缓冲区是否还有剩余，如果没有就将消息从队列中移除，如果队列中还有消息，那么继续发起write调用。

    重复一下，这里引用的代码都是yanf4j aio分支中的源码，感兴趣的朋友可以直接check out出来看看： http://yanf4j.googlecode.com/svn/branches/yanf4j-aio.在引入了aio之后，java对于网络层的支持已经非常完善，该有的都有了，java也已经成为服务器开发的首选语言之一。java的弱项在于对内存的管理上，由于这一切都交给了GC，因此在高性能的网络服务器上还是Cpp的天下。java这种单一堆模型比之erlang的进程内堆模型还是有差距，很难做到高效的垃圾回收和细粒度的内存管理。

    这里仅仅是介绍了aio开发的核心流程，对于一个网络框架来说，还需要考虑超时的处理、缓冲buffer的处理、业务层和网络层的切分、可扩展性、性能的可调性以及一定的通用性要求。

Generic's functions are :
1. remove type cast;
2. typesafe programming;

The key question of Generic:
1. the inheritance attribute of OO is not support: List<String> is not a type of List<Object>。

2. Collection<?> c: the parametered type is unknown. so you cant add elem into c.but you may get the elem in c and we know they are of type Object.

3、类型推断

static  < T >   void  fromArrayToCollection(T[] a, Collection  <  T  >  c)   { 

   for  (T o : a)   { 
         c.add(o);  //  correct  
      } 
 }

  对这个方法参数化类型T，由定义数据a和Collection时传入的共同决定，它们可以使用相同类型，也可以使用不同类型，当类型不同时，它们必须有继承关系，类型推断时使用较高的那个。
4， when to use <?> or <T> :他们主要用在泛型方法，T相比?，它有名称，可多次使用来表达依赖关系。所以在不表达依赖关系的地方就应该使用?。它简单、灵活。

而且有趣的是，它们并非水火不容，反而可以精妙配合，如下：  

1  class Collections { 
2
3  public static < T > void copy(List < T > dest, List < ? extends T > src) {  } 
4
5} 

这个合作使得dest 与 src 的依赖关系得以表达，同时让 src 的接纳范畴扩大了。假如我们只用泛型方法来实现：  

1  class Collections { 
2
3   public static < T, S extends T > void copy(List < T > dest, List < S > src) {  } 
4
5} 

那么S 的存在就显得有些不必要，有些不优雅。总的来说，通配符更简洁清晰，只要情况允许就应该首选。

5、由于普通数组是协变的，而GenricType由于List<String>不是List<Object>的子类型，所以它不能协变。可以使用?来new 一个数组。但是通常new完就要加元素，而？类型未知不可以产生对象的。所以最后使用Class<T> 类型做形参，实参用T.class就可以。这就是为什么Hibernate.load和get中会使用的.class的用法。比较新知识点是String.class就是Class<String>(String.class称字面类常量)。当传入Class<T> c 对象后，可以利用reflect来构造对象，并作状态设置。

什么是重构
重构是指在保持程序的全部功能的基础上改变程序结构的过程。重构的类型有很多，如更改类名，改变方法名，或者提取代码到方法中。每一次重构，都要执行一系列的步骤，这些步骤要保证代码和原代码相一致。

重构的理由：为整理，为扩展，为优雅。

在Eclipse下的重构：

重构会关联多个文件，在一次重构时，不可再修改并保存文件，重构无法撤销或重做。

Eclipse中的重构类型
       如果你看一下Eclipse的重构菜单，可以看到四部分。第一部分是撤销和重做。其他的三部分包含Eclipse提供的三种类型的重构。
第一种类型的重构改变代码的物理结构，像Rename和Move。第二种是在类层次上改变代码结构，例如Pull Up和Push Down。第三种是改变类内部的代码，像Extract Method和Encapsulate Field。这三部分的重构列表如下。
 
类型1 物理结构
l         Rename
l         Move
l         Change Method signature
l         Convert Anonymous Class to Nested
l         Convert Member Type to New File：内部类提出一个单独类。
 
类型2 类层次结构
l         Push Down：将父类中方法或成员移到子类。
l         Push Up
l         Extract Interface
l         Generalize Type (Eclipse 3)
l         User Supertype Where Possible
类型3 类内部结构
l         Inline
l         Extract Method
l         Extract Local Variable
l         Extract Constant
l         Introduce Parameter：引进参数替换local var
l         Introduce Factory
l         Encapsulate Field


表从Eclipse帮助中提取，列出了各种重构支持的Java资源类型，对应的快捷键。

名字	可应用的Java元素	快捷键
Undo	在一次重构后可执行	Alt + Shift + Z
Redo	在一次撤销重构后可执行	Alt + Shift + Y
Rename	对方法，成员变量，局部变量，方法参数，对象，类，包，源代码目录，工程可用。	Alt + Shift + R
Move	对方法，成员变量，局部变量，方法参数，对象，类，包，源代码目录，工程可用。	Alt + Shift + V
Change Method Signature	对方法可用。	Alt + Shift + C
Convert Anonymous Class to Nested	对匿名内部类可用。
Move Member Type to New File	对嵌套类可用。
Push Down	对同一个类中成员变量和方法可用。
Pull Up	对同一个类中成员变量和方法，嵌套类可用。
Extract Interface	对类可用。
Generalize Type	对对象的声明可用。
Use Supertype Where Possible	对类可用。
Inline	对方法，静态final类，局部变量可用。	Alt + Shift + I
Extract Method	对方法中的一段代码可用。	Alt + Shift + M
Extract Local Variable	对选中的与局部变量相关的代码可用。	Alt + Shift + L
Extract Constant	对静态final类变量，选中的与静态final类变量相关的代码可用。
Introduce Parameter	对方法中对成员变量和局部变量的引用可用。
Introduce Factory	对构造方法可用。
Convert Local Variable to Field	对局部变量可用。	Alt + Shift +

Ctrl+D: 删除当前行    

Ctrl+Alt+↓ 复制当前行到下一行(复制增加)

Ctrl+Alt+↑ 复制当前行到上一行(复制增加)

Alt+↓ 当前行和下面一行交互位置(特别实用,可以省去先剪切,再粘贴了)

Alt+↑    当前行和上面一行交互位置(同上)

Alt+← 前一个编辑的页面

Alt+→ 下一个编辑的页面(当然是针对上面那条来说了)

Alt+Enter 显示当前选择资源(工程,or 文件 or文件)的属性

Shift+Enter 在当前行的下一行插入空行(这时鼠标可以在当前行的任一位置,不一定是最后)

Shift+Ctrl+Enter 在当前行插入空行(原理同上条)

Ctrl+Q    定位到最后编辑的地方

Ctrl+L 定位在某行 (对于程序超过100的人就有福音了)

Ctrl+M 最大化当前的Edit或View (再按则反之)

Ctrl+/    注释当前行,再按则取消注释

Ctrl+O    快速显示 OutLine

Ctrl+T    快速显示当前类的继承结构

Ctrl+W 关闭当前Editer

Ctrl+K    参照选中的Word快速定位到下一个

Ctrl+E 快速显示当前Editer的下拉列表(如果当前页面没有显示的用黑体表示)

Ctrl+/(小键盘) 折叠当前类中的所有代码

Ctrl+×(小键盘) 展开当前类中的所有代码

Ctrl+Space 代码助手完成一些代码的插入(但一般和输入法有冲突,可以修改输入法的热键,也可以暂用Alt+/来代替)

Ctrl+Shift+E 显示管理当前打开的所有的View的管理器(可以选择关闭,激活等操作)

Ctrl+J 正向增量查找(按下Ctrl+J后,你所输入的每个字母编辑器都提供快速匹配定位到某个单词,如果没有,则在stutes line中显示没有找到了,查一个单词时,特别实用,这个功能Idea两年前就有了)

Ctrl+Shift+J 反向增量查找(和上条相同,只不过是从后往前查)

Ctrl+Shift+F4 关闭所有打开的Editer

Ctrl+Shift+X    把当前选中的文本全部变为大写

Ctrl+Shift+Y    把当前选中的文本全部变为小写

Ctrl+Shift+F 格式化当前代码

Ctrl+Shift+P 定位到对于的匹配符(譬如{}) (从前面定位后面时,光标要在匹配符里面,后面到前面,则反之)

下面的快捷键是重构里面常用的,本人就自己喜欢且常用的整理一下(注:一般重构的快捷键都是Alt+Shift开头的了)

Alt+Shift+R 重命名 (是我自己最爱用的一个了,尤其是变量和类的Rename,比手工方法能节省很多劳动力)

Alt+Shift+M 抽取方法 (这是重构里面最常用的方法之一了,尤其是对一大堆泥团代码有用)

Alt+Shift+C 修改函数结构(比较实用,有N个函数调用了这个方法,修改一次搞定)

Alt+Shift+L 抽取本地变量( 可以直接把一些魔法数字和字符串抽取成一个变量,尤其是多处调用的时候)

Alt+Shift+F 把Class中的local变量变为field变量 (比较实用的功能)

Alt+Shift+I 合并变量(可能这样说有点不妥Inline)

Alt+Shift+V 移动函数和变量(不怎么常用)

Alt+Shift+Z 重构的后悔药(Undo)

Ctrl+Shift+U 选择选中的文字后非常类似于UE的列表查询

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/f128690011/archive/2007/06/24/1664354.aspx

Mysql中文乱码的几个解决方法

1 前言

　　与EJB2.1相比，EJB3.0规范引入了两个重要概念：依赖注入（DI：Dependency Injection）和截获器（Interceptor），本文首先介绍了这两个概念并给出相关示例，然后分析了EJB3.0规范在这两方面的不足之处，最终深入探讨了WebLogic Server 10对它们的支持和扩展。

2 依赖注入

　　2.1 基本概念

　　依赖注入是从开源社区的一些著名轻量级容器（如Spring、Pico container）中所发展出来的概念，其主要思想就是由容器而不是对象本身来负责处理对象之间的依赖关系。与传统的服务定位器相比，依赖注入具有易测试、弱侵入性等优点，这也就是为什么在最新的Java EE 5规范中引入它的原因。

　　对于EJB3.0来说，依赖注入就是由容器负责查找被依赖的对象并注入到依赖bean中，而bean本身不再需要进行JNDI或者context查询。此外，依赖注入发生在任何业务方法被调用之前，而且支持setter方法注入和域注入两种方式。

　　通过与标注结合使用，在bean类中声明依赖注入是非常简单的（当然，也可以在部署描述符文件中声明依赖注入）：

　　　　@EJB用于注入EJB业务对象
　　　　@PersistenceUnit 用于注入EntityManagerFactory
　　　　@PersistenceContext 用于注入EntityManager
　　　　@Resource 用于注入其它资源对象，如连接工厂、消息目标等

　　2.2 示例

@Stateless
public class ServiceBean implements Service {
private javax.sql.DataSource myDS;
@Resource(mappedName=“LocalDataSource")
public void setMyDS(javax.sql.DataSource ds) {this.myDS = ds; }
@EJB(beanName=“AccountBean")
private Account account;
}

　　在无状态会话bean ServiceBean中，声明了两个依赖：一个是数据源，一个是业务接口。在运行期间，EJB3.0容器一旦创建了ServiceBean的实例，就会分别通过方法注入和域注入将数据源对象和业务对象注入到ServiceBean中。

3 截获器

　　3.1 基本概念

　　作为EJB3.0中提出的新概念，截获器是可以对bean的业务方法和生命周期事件进行拦截的组件。截获器需要由@Interceptors 或发布描述符文件中相关的标签指定。截获器可以带有状态而且可以进行依赖注入，其生命周期与其所绑定的EJB bean实例的生命周期一致。

　　定义在截获器中用于拦截目的的方法被称为截获器方法，其中，针对业务方法的截获器方法通过@AroundInvoke标注或发布描述符文件中相关的标签指定；针对生命周期回调的截获器方法通过@PostConstruct, @PreDestroy等标注或发布描述符文件中对应的标签指定。

　　截获器分为四类：

　　　　缺省截获器：可作用于ejb-jar中定义的所有EJB bean。缺省截获器只能定义在DD中，不存在相应的标注
　　　　类级截获器：只能作用于所指定的EJB bean
　　　　方法级截获器：只能作用于所指定的某个EJB bean业务方法，方法级截获器不能用于拦截bean的生命周期事件
　　　　bean 级截获器：又被称为自我截获器，因为截获器同时就是EJB bean本身，此时相关的截获器方法只能作用于该EJB

　　3.2 截获器链的调用顺序

　　因为可以为EJB定义多个截获器，所以存在截获器链的调用顺序问题，缺省情况下，以下原则被遵循：

　　　　调用顺序依次是缺省截获器、类级截获器、方法级截获器以及bean级截获器
　　　　对于同类别的截获器，按照声明的顺序调用
　　　　总是优先调用父类的截获器方法。

　　此外，EJB3.0规范还提供了更灵活的选项，详细信息请参考EJB3.0规范中“截获器”一节：

　　　　在发布描述符文件中设置“exclude-default-interceptors” 可以取消对缺省截获器的调用，而应用“exclude-class-interceptors”则取消对类级截获器的调用
　　　　为了替换缺省的截获器链调用顺序，可以设置发布描述符文件的“interceptor-order”。

　　3.3 示例

@Stateless(name="Trader")
@Interceptors(ClassInterceptor.class)
public class TraderBean implements Trader {
@Interceptors(MethodInterceptor.class)
public String sell(String stockSymbol) {
…
}
@AroundInvoke
public Object selfInterceptor(InvocationContext) throws Exception {
…
}
}

　　在无状态会话bean TraderBean中，声明了两个截获器：一个类级截获器，一个方法级截获器，此外，通过使用@AroundInvoke标注，TraderBean的方法selfInterceptor被声明为截获器方法，所以TraderBean就是bean级截获器。

4 EJB3.0规范在依赖注入和截获器方面的不足

　　从依赖注入方面来说，EJB3.0目前支持的注入类型是非常有限的，诸如List、Map之类的集合类型都不能被注入。

　　另一方面，EJB3.0的截获器可被看作是一种AOP模型，截获器类相当于方面（Aspect），而截获器方法相当于通知（Advice），但这种AOP是非常简单的：

　　　　不支持引入（Introduction）；
　　　　不支持切入点（Pointcut）模式
　　　　通过标注告诉容器某个EJB需要使用截获器，从而使得这种AOP模型具有一定的侵入性

5 WebLogic Server 10 EJB3.0容器简介

　　 5.1 Pitchfork 简介

　　Pitchfork是由Interface21与BEA合作开发的一个具有Apache License的开源项目，作为Spring的“增值”项目，开发Pitchfork有两个目的：

　　　　当前应用服务器可使用Pitchfork实现Java EE 5中的依赖注入，标注处理以及EJB3.0中的截获器。
　　　　在Spring容器中支持Java EE 5的标注

　　5.2 WebLogic Server 10 EJB3.0容器的架构

　　WebLogic Server 10完全支持Java EE 5和EJB3.0，其EJB3.0 容器是基于Pitchfork来实现依赖注入与截获器的，而Pitchfork又利用了Spring的依赖注入和AOP。此时，WebLogic Server 10的用户有两种选择：

　　　　使用EJB3.0标准模型： EJB bean实例由EJB容器创建，然后由Pitchfork实施Java EE 5 的依赖注入和截获器，这是WebLogic Server 10的缺省配置。
　　　　使用Spring扩展模型：EJB bean实例由Spring容器创建并实施Spring的依赖注入，然后由Pitchfork实施Java EE 5的依赖注入，EJB3.0截获器和Spring AOP。

6 Spring扩展模型

　　6.1 使用Spring扩展模型的主要开发步骤

　　　　下载某个版本的Spring类库（最好是由BEA指定的版本），至少需要包括以下jar文件：spring.jar, aspectjweaver.jar, commons-logging.jar, log4j-1.2.14.jar，如果需要，还可以增加其它jar文件。
　　　　将这些jar文件加入到WebLogic Server 10的类路径中。
　　　　创建文本文件Weblogic.application.ComponentFacotry以标识当前应用将使用Spring扩展模型，其内容只有一行：　　　　Weblogic.application.SpringComponentFactory。
　　　　创建/META-INF/services子目录，然后放入前面创建的文件Weblogic.application.ComponentFacotry
　　　　建立Spring 配置文件，并放入到/META-INF目录下，如果是EJB应用程序，Spring配置文件的名字应该是spring-ejb-jar.xml，如果是Web应用程序，Spring配置文件的名字则是spring-web.xml.
　　　　为了使EJB bean能利用Spring的依赖注入与AOP，需要同时将其定义在spring-ejb-jar.xml（或spring-web.xml）中，从Spring角度来看，这就是一个普通的Spring bean，只不过它的id或name必须与对应的EJB　name相同。
　　　　将上述目录文件、相关的Java类、部署描述符等打包成标准的jar文件、war文件或ear文件。

　　需要注意的是，在Spring配置文件中定义的bean，如果它也是一个EJB bean，则该Spring bean的class属性会被忽略以避免潜在的冲突。

　　6.2 示例

　　示例一：利用Spring的依赖注入。本例将演示两点，(1) 注入一个集合类型，(2) 注入一个Spring POJO对象

　　(1) 开发一个bean类

@Stateless(name="AccountManagementBean")
@Remote({examples.AccountManagement.class})
public class AccountManagementBean
{
private List accountList;
private BusinessObject businessObject;
public boolean doBusiness(String account) {
if (accountList.contains(account)) {
businessObject.doBusiness();
return true;
}
return false;
}
public BusinessObject getBusinessObject() {
return businessObject;
}
public void setBusinessObject(BusinessObject businessObject) {
this.businessObject = businessObject;
}

public List getAccountList() {
return accountList;
}
public void setAccountList(List accountList) {
this.accountList = accountList;
}
}
　　(2) 一个POJO

public class BusinessObjectImpl implements BusinessObject
{
private String result;

public void doBusiness() {
System.out.println("I am doing business, the result is: " + result);
}

public String getResult() {
return result;
}

public void setResult(String result) {
this.result = result;
}
}
　　(3) Spring-ejb-jar.xml

…
＜beans＞
＜bean name="BusinessObject" class="examples.BusinessObjectImpl"＞
＜property name="result" value="success" /＞
＜/bean＞
＜bean id="AccountManagementBean"＞
＜property name="businessObject" ref="BusinessObject" /＞
＜property name="accountList"＞
＜list＞
＜value＞Safin＜/value＞
＜value＞Amy＜/value＞
＜value＞Albert＜/value＞
＜value＞Yang＜/value＞
＜/list＞
＜/property＞
＜/bean＞
＜/beans＞

　　示例二：利用Spring 的AOP。本例演示了混合使用JEE interceptor、基于代理的Spring AOP以及AspectJ的Aspect

　　(1) 开发一个bean类

@Stateless(name="AccountManagementBean")
@Remote({examples.AccountManagement.class})
public class AccountManagementBean
{
public AccountManagementBean() {}
@Interceptors({examples.JEEInterceptor.class})
public boolean doBusiness(String account) {
System.out.println("I am doing business " + account);
return true;
}
}

　　(2) 开发一个JEE interceptor

public class JEEInterceptor {
@AroundInvoke
private Object intercept(InvocationContext inv) throws Exception{
System.out.println("I am in JEEInterceptor.intercept()");
return inv.proceed();
}
}

　　(3) 开发一个Advice

public class SimpleAdvice implements MethodInterceptor{
public Object invoke(MethodInvocation invocation) throws Throwable {
System.out.println("I am in Spring AOP interceptor");
return invocation.proceed();
}
}

　　(4) 开发一个Pointcut

public class SimpleStaticPointcut extends StaticMethodMatcherPointcut {
public boolean matches(Method method, Class cls) {
return "doBusiness".equals(method.getName());
}
public ClassFilter getClassFilter() {
return new ClassFilter() {
public boolean matches(Class cls) {
return AccountManagementBean.class.isAssignableFrom(cls);
}
};
}
}

　　(5) 开发一个AspectJ Aspect

@Aspect
public class Aspects {
@Around("execution(* examples.AccountManagementBean.doBusiness(..))")
public Object around(ProceedingJoinPoint pjp) {
System.out.println(“I am in AspectJ aspect);
Object retVal = null;
try {
retVal = pjp.proceed();
} catch (Throwable e) {
e.printStackTrace();
}
return retVal;
}
}

　　(5) Spring-ejb-jar.xml

＜?xml version="1.0" encoding="UTF-8"?＞
＜beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd"＞
＜bean id="AccountManagementBean" /＞
＜bean id="myAdvisor" class="org.springframework.aop.support.DefaultPointcutAdvisor"＞
＜property name="advice"＞
＜bean class=”examples.SimpleAdvice” /＞
＜/property＞
＜property name="pointcut"＞
＜bean class="examples.SimpleStaticPointcut" /＞
＜/property＞
＜/bean＞
＜bean id="MyAspect" class="examples.Aspects" /＞
＜/beans＞

　　6.3 优点

　　提供Spring扩展模型具有如下好处：

　　　　可以在同一个发布单元中混合使用EJB bean和Spring POJO，而且一个EJB bean可以同时是一个Spring POJO，因此被EJB容器和Spring容器同时管理
　　　　有效地克服了EJB3.0 规范在依赖注入和截获器方面的一些缺陷
　　　　为用户提供更灵活的选择：
　　　　　　如果标准的EJB 依赖注入以及截获器可以满足应用需求，或者可移植性是优先考虑的因素，则选用标准模型
　　　　　　如果标准的EJB依赖注入以及截获器不能满足应用需求，或者不用考虑可移植性，或者需要集成一些Spring应用，则应选用Spring扩展模型

7 Spring AOP在WebLogic Server 10 Spring扩展模型中的使用限制及说明

　　7.1 代理生成方式

　　Spring AOP采用的是一种基于代理的框架，目前有两种生成代理的方式：JDK动态代理和CGLIB。在WebLogic Server 10的Spring扩展模型中，目前不支持CGLIB方式，这主要是因为生成的EJB类都是final的

　　7.2 代理创建

　　在Spring中，代理或者是通过诸如ProxyFactoryBean之类的工厂bean明确创建，或者是通过“自动代理”创建器隐含创建。

　　在WebLogic Server 10中，Pitchfork已经隐含提供了类似的“自动代理”机制，所以原有的Spring代理创建方式是无效的，换句话说，用户只需要在Spring配置文件中定义目标bean以及对应的Spring Advisor和AspectJ Aspect, 不需要再定义ProxyFactoryBean和“自动代理”创建器，Pitchfork会自动为我们创建AOP代理

　　7.3 截获的顺序问题

　　在Spring扩展模型中，可以混合使用JEE截获器、Spring Advisor以及AspectJ Aspect，此时的调用顺序为JEE截获器、Spring Advisor以及AspectJ Aspect。

　　7.4 bean的实例化模式

　　缺省方式下，Spring bean是Singleton的，即Spring容器总是返回同一个bean实例，在Spring扩展模型中，这意味着同一个Spring Advisor或AspectJ Aspect实例将被应用到不同的EJB bean实例上，如果Advisor或Aspect实例是有状态的，这可能会产生问题，为此我们推荐如下的使用方式：

　　　SLSB & MDB
　　　　带有状态的Advisor或Aspect
　　　　　不推荐用带有状态的Advisor或Aspect，除非用户意识到相关的后果并认为这种后果是可以接收的，此时的实例化模式取决于具体应用
　　　　没有状态的Advisor或Aspect
　　　　　采用Singleton实例化模式
　　　SFSB
　　　　带有状态的Advisor或Aspect
　　　　　正常情况下应该采用的实例化模式是Prototype，除非用户意识到采用Singletong的后果并认为这种后果是可以接收的
　　　　没有状态的Advisor或Aspect
　　　　　采用Singleton实例化模式

8 结束语

　　依赖注入和截获器的引入，使得EJB3.0克服了很多EJB2.1的缺点，但与开源社区中流行的轻量级容器相比，EJB3.0无论是在依赖注入的范围还是在AOP的易用性方面都还存在一定的不足。而最近BEA所推出的WebLogic Server 10不但完全支持EJB3.0，而且对其进行了有效扩展，这使得一方面可以充分利用在开源社区中出于领导地位的Spring在依赖注入和AOP方面的强大能力，另一方面又紧密依托WebLogic Server 10在事务、安全、集群方面领先的技术，从而为EJB3.0用户开发出易维护、可扩展、高效率的企业应用程序打下坚实的基础。

作者简介

　　李钢 dev2devid: cc_masterli ，BEA研发中心WebLogic Server 研发团队成员，西安交通大学计算机专业博士，一直从事java中间件领域的研发，2005年加入BEA，现为EJB3 中国研发小组的负责人。