1package test;
 2
 3import org.slf4j.Logger;
 4import org.slf4j.LoggerFactory;
 5
 6public class Test {
 7    final static Logger logger = LoggerFactory.getLogger(Test.class);
 8    
 9    public static void main(String[] args) {
10        logger.error("test");
11    }
12
13}
14

slf4j-log4j12-1.5.8.jar
slf4j-api-1.5.8.jar
log4j-1.2.15.jar

 1package test;
 2
 3import java.sql.Connection;
 4import java.sql.DriverManager;
 5import java.sql.ResultSet;
 6import java.sql.Statement;
 7
 8public class jdbcsample {
 9    static public void main(String[] argc) throws Exception {
10        String connectionURL = "jdbc:log4jdbc:mysql://127.0.0.1:3306/sampledb";
11
12        Class.forName("net.sf.log4jdbc.DriverSpy").newInstance();
13        Connection connection = DriverManager.getConnection(connectionURL,
14                "root", "1234");
15
16        Statement statement = connection.createStatement();
17        ResultSet rs = statement.executeQuery("SELECT * FROM customers");
18
19        while (rs.next()) {
20            System.out.println(rs.getString(1));
21        }
22        rs.close();
23
24    }
25}
26

add the jar file:
log4jdbc3-1.2beta1.jar
mysql-connector-java-5.1.12-bin.jar

hibernate.dialect=net.sf.hibernate.dialect.MySQLDialect
hibernate.connection.driver_class=net.sf.log4jdbc.DriverSpy
hibernate.connection.url=jdbc:log4jdbc:mysql://localhost:3306/SAMPLEDB
hibernate.connection.username=root
hibernate.connection.password=1234
hibernate.show_sql=false

http://park3.wakwak.com/~ozashin/sw_tips/webapp_tips/sjis_charset.html

文字コードについて（シフトJISの問題）

文字コードをシフトJISで開発し、Windowsのサーバで動かす場合の文字コード問題について示します。

厳密にいうとWindowsが扱う文字コードは、シフトＪＩＳでは、ありません。MS932です。または、コードページ CP932ともいいます。MS932は、マ社がシフトＪＩＳを拡張して定義したコード体系です。

で、ここで何が問題になるかというと、クライアントへの出力をcharset="Shift_JIS"とか定義して、アプリケーションサーバーなど が一生懸命シフトＪＩＳで出力しようとすると、ある文字列が文字化けするのです。ようは、MS932にある文字コードはシフトＪＩＳには、ないので、'? 'で出力されるということです。なお、OC4JやJBuilderで利用するtomcatは、MS932で出力しようとするので、あんまり文字化けしませ ん。

Java内部で扱う文字コードは、Unicodeです。ここでシフトＪＩＳとUnicodeのマッピングとMS932とUnicodeのマッピング の違いによって、思わぬ、文字化けが発生するのです。ちなみに、JSPファイルにじか書きしてあるもじは、そのまま出力されるので問題はありません。
Javaプログラムを通して、Unicodeからcharsetで定義された文字が出力されるとき文字化けの対象となります。

具体的には、'～'、'∥'、'－'、'￠'、'￡'、'￢'などの一部の記号類です。
日本語のUnicodeベンダ依存文字表 http://www.ingrid.org/java/i18n/unicode.html を参照してください。

というわけで、Windowsで動かすのであれば、charsetを"Windows-31J"にしましょう！そうすれば、一部の文字コードを除い て解決です。
JSPの場合は、<%@ page contentType="text/html; charset=Windows-31J" %>と定義します。
Servletでは、

	private static final String CONTENT_TYPE = "text/html; charset=Windows-31J";
....
response.setContentType(CONTENT_TYPE);

のように実装します。charset="MS932"でもＯＫですが、http://www.ingrid.org/java/i18n/encoding/shift_jis.htmlに あるとおり、これからは、Windows-31Jでいくようです。

シフトＪＩＳがらみでもうひとつWAVE DASH問題（TILDE問題）というのがあります。これは、JDBCがらみというか、データベースの文字セットの問題というか、誰が根本的な原因かわか らないところがあります。Unicodeの実装が厳密に定義されていないので、ベンダごとで実装の仕方が違っているそうです。

Oracleを例にとって文字の流れを以下に示します。テスト環境は以下のとおり。

OS	Windows2000
データベースサーバ	Oracle8i R8.1.7
ＤＢ内部コード	JA16SJIS

ある入力フィールドに '～' を含んだ文字列を設定し、それをデータベースへ格納し、参照する場合、文字変換の流れは以下のようになります。

1. ブラウザ上では、Windows-31J(MS932)なので、'～'=0x8160
2. Javaプログラム内部では、Unicodeなので、JisAutoDetectなどで変換して、'～'=0xFF5E (FULL WIDTH TILDE)
3. データベースに格納された結果は、JA16SJISなので、'～'=0x8160
4. Javaプログラムがデータベースから文字をGETしたとき、'～'=0x301C (WAVE DASH)
5. 0x301Cを応答として出力すると、0x8160にマッピングできないので '?'となる。

この問題は、上記のようにcharsetをWindows31Jにしても回避できません。

ちなみに、Unicodeでいうところの '～' は、0x301C (WAVE DASH)になるのが、Unicodeコンソーシアムでは正しい実装方法だそうです。

(4)で、0x301Cに変換されているんだからＯＫじゃん、と思いますが、0x8160を0xFF5Eに変換するんだから、0x8160にするに は、0xFF5Eにしてあげなければならないのです。

この問題を回避するには、２通りあります。

1. (4)で0x301Cで変換された文字を0xFF5Eに再変換する。
2. Oracle9i R9.2以降でMS932がサポートされたデータベース内部コード "JA16SJISTILDE"を利用する。

しかし、(1)では、データベースをアクセスするたび、毎回再変換するので、パフォーマンスが落ちます。(2)では、いまさらOracle9に移行 できる予算がないし、検証しているひまもないという問題があります。
したがって、第３の回避方法として、運用で逃げる（'～'は、システム上扱えないコードとしてユーザに我慢してもらう）という手もあります。

ちなみに、私は、多少パフォーマンスが落ちてもＯＫということで、(1)で再変換の道を選びました。

まぁ、最初からOracle9iR9.2を選んでいれば、ＯＫですけどね。また、検証はしていませんが、EUC-JPでも同様の問題があって、 Oracle9iR9.2からJA16EUCTILDEがサポートされているようです。

Windowsで動かし、JISAutoで変換した場合のデフォルトコンバータは、誰の都合か知りませんが、以下のように変化しました。
まぁ、Windowsで動かす限り、Windows-31Jをcharsetにしておけば、JDK1.4.1以降でもＯＫのようです。

JMX を使用する監視と管理

Java 仮想マシン (JVM) には、JMX を使って JVM の監視と管理を可能にする機能が組み込まれています。また、実装されたアプリケーションを JMX で監視することもできます。

• JMX 用のシステムプロパティの設定
• JMX エージェントの有効化
  • ローカルの監視と管理
  • リモートの監視と管理
• プログラムによる JMX エージェントへの接続
• パスワードおよびアクセスファイルの使用
• JMX 管理および監視プロパティ

システムプロパティの設定

JMX エージェントを有効にして、動作を設定するには、JVM を起動するときに特定のシステムプロパティを設定する必要があります。コマンド行上で次のようにシステムプロパティを設定します。

java -Dproperty=value ...

この方法で任意の数のシステムプロパティを設定できます。値を指定しない場合、デフォルト値で設定されます。JMX 管理プロパティのフルセットは、表 1 に記載されています。JMX 管理および監視プロパティに記載したように設定ファイルでシステムプロパティを設定することもできます。

注:java (Java VM) をコマンド行から実行するには、JRE_HOME/bin をパスに追加する必要があります。ここで JRE_HOME は、JRE (Java Runtime Environment) を含むディレクトリです。代わりにコマンドを入力するときにフルパスを入力することもできます。

以下のドキュメントは、Java HotSpot VM によってサポートされている構文とコマンド行オプションのフルセットについて説明しています。

• Microsoft Windows 用 Java アプリケーション起動ツール
• Solaris オペレーティング環境用 Java アプリケーション起動ツール
• Linux 用 Java アプリケーション起動ツール

JMX エージェントの有効化

JMX によって Java プラットフォームを監視するには、以下の手順に従ってください。

1. JVM を起動するときに JMX エージェント (MBean サーバ) を有効にします。以下に対して JMX エージェントを有効にすることができます。
   • ローカル監視 - ローカルシステムで動作するクライアント管理アプリケーション用。
   • リモート監視 - リモートシステムで動作するクライアント管理アプリケーション用。
2. JVM を jconsole などの JMX 準拠のツールで監視します。詳細は、「jconsole の使用」を参照してください。

ローカルの監視と管理

ローカルアクセスに対して JMX エージェントを有効にするには、JVM または Java アプリケーションを起動するときにこのシステムプロパティを設定します。

com.sun.management.jmxremote

このプロパティを設定することにより、JVM 実装 MBean を登録し、RMI コネクタを専用インタフェース経由で公開して、JMX クライアントアプリケーションがローカルの Java プラットフォーム、すなわち、同一マシン上で動作する JVM を監視できるようにします。

たとえば、サンプルアプリケーションの Notepad 用の JMX エージェントは、以下のようにして有効にします。

cd JDK_HOME/demo/jfc/Notepad

java -Dcom.sun.management.jmxremote -jar Notepad.jar

ここで、JDK_HOME は、JDK がインストールされているディレクトリです。

jconsole の使用

jconsole によるローカルの監視は、開発およびプロトタイプ作成に便利です。jconsole 自体がかなりのシステムリソースを消費するため、jconsole をローカルで実稼働環境に使用することはお勧めしません。それよりは、jconsole をリモートシステムで使用して、監視されるプラットフォームから分離してください。

コマンドシェルで jconsole と入力して、jconsole を起動します。引数なしで jconsole を起動する場合、jconsole は自動的にすべてのローカル Java アプリケーションを検出し、監視したいアプリケーションを選択できるダイアログボックスを表示します。システムの監視には、オペレーティングシステムのファイルアクセス権が必要であるため、jconsole とアプリケーションは両方とも、同じユーザ名で実行する必要があります。

注:jconsole をコマンド行から実行するには、JAVA_HOME が JDK を含むディレクトリになっているパスに、JAVA_HOME/bin を追加する必要があります。あるいは、コマンドを入力するときにフルパスを入力することもできます。

jconsole の使用についての詳細は、「jconsole の使用」を参照してください。

リモートの監視と管理

リモートシステムからの監視と管理を可能にするには、JVM を起動するときにこのシステムプロパティを設定します。

com.sun.management.jmxremote.port=portNum

ここで、portNum は、JMX/RMI 接続を有効にしたいポート番号です。必ず未使用のポート番号を指定してください。ローカルアクセスに対して RMI コネクタを公開するのに加えて、このプロパティを設定することにより、標準名「jmxrmi」を使用して、特定のポートのプライベートな読み取り専用レジストリで追加の RMI コネクタを公開します。

注:以下に説明されているように、セキュリティ用に設定するプロパティの他に上記のシステムプロパティを設定する必要があります。

リモートの監視と管理には、権限のないユーザがアプリケーションを制御または監視できないようにするためにセキュリティが必要です。デフォルトで、 SSL (secure sockets layer) 経由のパスワード認証が有効になっています。以下のセクションで説明されているように、パスワード認証と SSL を個別に無効にすることができます。

• パスワード認証の使用
• パスワード認証の無効化
• SSL の使用
• クライアント SSL 認証の使用
• SSL の無効化
• セキュリティの無効化

JMX エージェントをリモートで使用できるようにしたら、「jconsole によるリモート監視」で説明されているように jconsole を使ってアプリケーションを監視できます。

パスワード認証の使用

デフォルトでは、リモート監視で JMX エージェントを有効にすると、JMX エージェントはパスワード認証を使用します。ただし、パスワードを設定する方法は、シングルユーザ環境にいるか、マルチユーザ環境にいるかによって異なります。

パスワードはパスワードファイルにクリアテキストで格納されるため、監視用の通常のユーザ名とパスワードを使用することはお勧めできません。代わりに、monitorRole および controlRole などのパスワードファイルで指定したユーザ名を使用します。詳細は、「パスワードおよびアクセスファイルの使用」を参照してください。

シングルユーザ環境: JRE_HOME/lib/management ディレクトリで以下の手順でパスワードファイルを設定します。

1. パスワードのテンプレートファイル、jmxremote.password.template を management.jmxremote.password にコピーします。
2. ファイルアクセス権を設定して、自分だけがパスワードファイルを読み取りおよび書き込みできるようにします。
3. monitorRole や controlRole などのロールに対するパスワードを追加します。

マルチユーザ環境: JRE_HOME/lib/managementディレクトリで以下の手順でパスワードファイルを設定します。

1. パスワードのテンプレートファイル、jmxremote.password.template をホームディレクトリにコピーします。
2. ファイルアクセス権を設定して、所有者だけがパスワードファイルを読み取りおよび書き込みできるようにします。
3. monitorRole や controlRole などのロールに対するパスワードを追加します。
4. JVM を起動するときにシステムプロパティを設定します。

   com.sun.management.jmxremote.password.file=pwFilePath

   ここで、pwFilePath はパスワードファイルへのパスです。

パスワード認証の無効化

リモート監視のパスワード認証は、デフォルトで有効になっています。パスワード認証を無効にするには、JVM を起動するときに以下のシステムプロパティを設定します。

com.sun.management.jmxremote.authenticate=false

ここで、portNum は、使用するポート番号です。必ず未使用のポート番号を指定してください。

パスワード認証を無効にする場合、「セキュリティの無効化」で説明しているように SSL を無効にすることもできます。「クライアントの SSL 認証の有効化」で説明しているようにパスワードを無効にして、SSL クライアント認証を有効にしたい場合もあります。

警告: この構成は安全ではありません。JMX ポート番号およびホスト名を知っている (または推測する) リモートユーザが Java アプリケーションおよびプラットフォームを監視および制御できます。開発用のシステムなら許容されるかもしれませんが、実稼働システムにはお勧めしません。

SSL の使用

SSL (Secure sockets layer) は、リモート監視および管理を有効にするときにデフォルトで有効になっています。SSL を使用するには、JMX エージェント (MBean サーバ) が動作するシステム上でデジタル証明書を設定して、次に SSL を正しく設定します。コマンド行ユーティリティ keytool を使用して、証明書を操作します。通常の手順は以下のとおりです。

1. サーバ上でまだ鍵ペアと証明書を設定していない場合は以下の手順に従います。
   1. keytool -genkey コマンドで鍵ペアを生成します。
   2. keytool -certreq コマンドで認証局 (CA) に署名付き証明書を要求します。
   3. keytool -import コマンドで証明書をキーストアにインポートします。「証明書のインポート」を参照してください。
      詳細および例については、「keytool - 鍵および証明書管理ツール」(Solaris および Linux) (Windows)を参照してください。
2. サーバシステム上で SSL を設定します。このドキュメントでは、SSL の設定とカスタマイズについて詳細には説明しませんが、通常、次の表に記載されているシステムプロパティを設定する必要があります。詳細は、JSSE ガイドの「デフォルト鍵およびトラストストア、ストアタイプ、およびストアパスワードのカスタマイズ」を参照してください。

詳細は、「keytool - 鍵および証明書管理ツール(Solaris および Linux) (Windows)」および「JSSE ガイド」を参照してください。

クライアント SSL 認証の有効化

クライアント SSL 認証を有効にするには、JVM を起動するときにこのシステムプロパティを設定します。

com.sun.management.jmxremote.ssl.need.client.auth=true

クライアント SSL 認証を使用するには、SSL を有効 (デフォルト) にしておく必要があります。

この構成では、クライアントシステムが有効なデジタル証明書を持つ必要があります。「SSL の使用」で説明したとおりに証明書をインストールして、SSL を設定する必要があります。

SSL の無効化

リモート監視で SSL を無効にするには、JVM を起動するときにこのシステムプロパティを設定します。

com.sun.management.jmxremote.ssl=false

パスワード認証は、セキュリティの無効化

パスワード認証と SSL の両方を無効 (セキュリティなし) にするには、JVM を起動するときにこれらのシステムプロパティを設定します。

com.sun.management.jmxremote.authenticate=false

com.sun.management.jmxremote.ssl=false

警告:この構成は安全ではありません。JMX ポート番号およびホスト名を知っている (または推測する) リモートユーザが Java アプリケーションおよびプラットフォームを監視および制御できます。開発用のシステムなら許容されるかもしれませんが、実稼働システムにはお勧めしません。

jconsole によるリモート監視

リモートアプリケーションを監視するには、次のように jconsole を起動します。

jconsole hostName:portNum

ここで、hostName は、アプリケーションを実行するシステム名で、portNum は、JVM を起動するときに指定したポート番号です。ホスト名とポート番号を省略して、jconsole が提供するダイアログボックスに入力することもできます。

注: jconsole をコマンド行から実行するには、JAVA_HOME が JDK を含むディレクトリになっているパスに、JAVA_HOME/bin を追加する必要があります。あるいは、コマンドを入力するときにフルパスを入力することもできます。

jconsole の使用についての詳細は、「jconsole の使用」を参照してください。

プログラムによる JMX エージェントへの接続

JMX エージェントを有効にしたら、以下の URL を使ってサービスにアクセスできます。

service:jmx:rmi:///jndi/rmi://hostName:portNum/jmxrmi

ここで、hostName はホスト名で portNum は、JMX エージェントを有効にしたときに指定したポート番号です。

次のように、URL を使って、javax.management.remote.JMXServiceURL オブジェクトのインスタンスを生成し、次に JMXConnectorFactory.connect メソッドを使用して接続を作成することにより、クライアントはエージェントへのコネクタを作成できます。

JMXServiceURL u = new JMXServiceURL(

"service:jmx:rmi:///jndi/rmi:// “ + hostName + ":"+ portNum +  "/jmxrmi");

JMXConnector c = JMXConnectorFactory.connect(u); 

パスワードおよびアクセスファイルの使用

パスワードおよびアクセスファイルは、リモート監視および管理のセキュリティを制御します。これらのファイルは、デフォルトでは、JRE_HOME/lib/management にあり、標準の Java プロパティファイルフォーマットです。フォーマットに関する詳細は、「java.util.properties」を参照してください。

パスワードファイル

パスワードファイルは、さまざまなロールとそのパスワードを定義します。アクセス制御ファイル (デフォルトでは、jmxremote.access) は、それぞれのロールに許可されるアクセス権を定義します。ロールを機能させるには、パスワードとアクセスファイルの両方にエントリを持つ必要があります。

JRE には、jmxremote.password.template という名前のパスワードファイルテンプレートがあります。このファイルを JRE_HOME/lib/management/jmxremote.password またはホームディレクトリにコピーして、アクセスファイルで定義したロールのパスワードを追加します。

パスワードファイルにはパスワードがクリアテキストで含まれるため、必ず所有者だけがこのファイルへの読み取りおよび書き込みアクセス権を持つようにしてください。セキュリティ上の理由から、システムは所有者だけがファイルを読み取りまたは書き込み可能であることを確認し、そうでない場合は終了します。このため、マルチユーザ環境では、パスワードファイルをホームディレクトリなどの非公開の場所に置きます。

プロパティ名はロールで、関連付けられた値はロールのパスワードです。

たとえば、パスワードファイルのエントリの例は次のようになります。

# The "monitorRole" role has password "QED".

# The "controlRole" role has password "R&D".

monitorRole QED

controlRole R&D

アクセスファイル

デフォルトでは、アクセスファイルは、jmxremote.access という名前です。プロパティ名はパスワードファイルと同じ領域からの ID です。関連する値は「readonly」または「readwrite」のいずれかにする必要があります。

アクセスファイルはロールとアクセスレベルを定義します。デフォルトでは、アクセスファイルは次の 2 つの主要なロールを定義します。

• monitorRole - 監視のための読み取り専用アクセスを許可します。
• controlRole - 監視および管理のために読み取り/書き込みアクセス権を許可します。

アクセス制御エントリは、ロール名および関連するアクセスレベルで構成されています。ロール名には、スペースやタブを含めることはできず、パスワードファイル内のエントリに対応している必要があります。アクセスレベルは次のいずれかです。

• readonly: MBean の属性に読み取りアクセスを許可します。監視の場合、これは、このロールのリモートクライアントが測定を読み取ることができるが、実行プログラムの環境を変更するアクションは実行できないことを意味します。
• readwrite: MBean の属性への読み取りおよび書き込みアクセス、属性への操作の呼び出し、これらの属性の作成または削除を許可します。アプリケーションの操作を妨害できるのは、信頼できるクライアントだけであるため、このアクセス権は信頼できるクライアントにだけ許可する必要があります。

ロールは、アクセスファイル内で 1 つのエントリだけを持つ必要があります。ロールにエントリがない場合、アクセス権はありません。ロールに複数のエントリがある場合、最後のエントリが優先されます。

アクセスファイルの通常の事前定義のロールは次のとおりです。

# The "monitorRole" role has readonly access.

# The "controlRole" role has readwrite access.

monitorRole readonly

controlRole readwrite

JMX 管理および監視プロパティ

構成ファイルまたはコマンド行で、管理と監視のプロパティを設定できます。コマンド行で指定したプロパティは、構成ファイル内のプロパティを無効にします。構成ファイルのデフォルトの場所は、JRE_HOME/lib/management/management.properties です。ここで JRE_HOME は、Java 実行時環境がインストールされているディレクトリです。com.sun.management.jmxremote または com.sun.management.jmxremote.port のいずれかのコマンド行プロパティが設定されている場合、JVM はこのファイルを読み取ります。SNMP 管理は同じ構成ファイルを使用します。詳細は、「SNMP 監視および管理」を参照してください。

次のコマンド行オプションでこの構成ファイルに別の場所を指定することもできます。

com.sun.management.config.file=ConfigFilePath

ここで、ConfigFilePath は、この構成ファイルへのパスです。

次の表は、すべての JMX 監視および管理プロパティを示しています。

構成エラー

MBean サーバ、RMI レジストリ、またはコネクタの起動中にエラーが発生した場合、JVM は例外をスローして終了します。構成エラーには以下のものがあります。

• ポート番号へのバインドの失敗
• 無効なパスワードファイル
• 無効なアクセスファイル
• パスワードファイルが所有者以外に読み取り可能になっている

アプリケーションでセキュリティマネージャを実行している場合は、セキュリティ権限ファイルに追加の権限が必要です。

http://pengjiaheng.spaces.live.com/blog/cns!2DAA368B386E6AEA!770.entry?wa=wsignin1.0

最近总结的一些东西，基本上是网上一些资料的汇总。

一、相关概念

基本回收算法

1. 引用计数（Reference Counting）
   比较古老的回收算法。原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只用收集计数为0的对象。此算法最致命的是无法处理循环引用的问题。
2. 标记-清除（Mark-Sweep）
   此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，同时，会产生内存碎片。
3. 复制（Copying）
   此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。次算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不过出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。
4. 标记-整理（Mark-Compact）
   此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。
5. 增量收集（Incremental Collecting）
   实施垃圾回收算法，即：在应用进行的同时进行垃圾回收。不知道什么原因JDK5.0中的收集器没有使用这种算法的。
6. 分代（Generational Collecting）
   基于对对象生命周期分析后得出的垃圾回收算法。把对象分为年青代、年老代、持久代，对不同生命周期的对象使用不同的算法（上述方式中的一个）进行回收。现在的垃圾回收器（从J2SE1.2开始）都是使用此算法的。

如上图所示，为Java堆中的各代分布。

1. Young（年轻代）
   年轻代分三个区。一个Eden区，两个Survivor区。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。
2. Tenured（年老代）
   年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。
3. Perm（持久代）
   用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=<N>进行设置。

1. Scavenge GC
   一般情况下，当新对象生成，并且在Eden申请空间失败时，就好触发Scavenge GC，堆Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。
2. Full GC
   对整个堆进行整理，包括Young、Tenured和Perm。Full GC比Scavenge GC要慢，因此应该尽可能减少Full GC。有如下原因可能导致Full GC：
   • Tenured被写满
   • Perm域被写满
   • System.gc()被显示调用
   • 上一次GC之后Heap的各域分配策略动态变化

分代垃圾回收过程演示

二、垃圾回收器

目前的收集器主要有三种：串行收集器、并行收集器、并发收集器。

1. 串行收集器
   
   使用单线程处理所有垃圾回收工作，因为无需多线程交互，所以效率比较高。但是，也无法使用多处理器的优势，所以此收集器适合单处理器机器。当然，此收集器也可以用在小数据量（100M左右）情况下的多处理器机器上。可以使用-XX:+UseSerialGC打开。
   
2. 并行收集器
   
   1. 对年轻代进行并行垃圾回收，因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用。使用-XX:+UseParallelGC.打开。并行收集器在J2SE5.0第六6更新上引入，在Java SE6.0中进行了增强--可以堆年老代进行并行收集。如果年老代不使用并发收集的话，是使用单线程进行垃圾回收，因此会制约扩展能力。使用-XX:+UseParallelOldGC打开。
   2. 使用-XX:ParallelGCThreads=<N>设置并行垃圾回收的线程数。此值可以设置与机器处理器数量相等。
   3. 此收集器可以进行如下配置：
      • 最大垃圾回收暂停:指定垃圾回收时的最长暂停时间，通过-XX:MaxGCPauseMillis=<N>指定。<N>为毫秒.如果指定了此值的话，堆大小和垃圾回收相关参数会进行调整以达到指定值。设定此值可能会减少应用的吞吐量。
      • 吞吐量:吞吐量为垃圾回收时间与非垃圾回收时间的比值，通过-XX:GCTimeRatio=<N>来设定，公式为1/（1+N）。例如，-XX:GCTimeRatio=19时，表示5%的时间用于垃圾回收。默认情况为99，即1%的时间用于垃圾回收。
3. 并发收集器
   可以保证大部分工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，此收集器适合对响应时间要求比较高的中、大规模应用。使用-XX:+UseConcMarkSweepGC打开。
   
   1. 并发收集器主要减少年老代的暂停时间，他在应用不停止的情况下使用独立的垃圾回收线程，跟踪可达对象。在每个年老代垃圾回收周期中，在收集初期并发收集器会对整个应用进行简短的暂停，在收集中还会再暂停一次。第二次暂停会比第一次稍长，在此过程中多个线程同时进行垃圾回收工作。
   2. 并发收集器使用处理器换来短暂的停顿时间。在一个N个处理器的系统上，并发收集部分使用K/N个可用处理器进行回收，一般情况下1<=K<=N/4。
   3. 在只有一个处理器的主机上使用并发收集器，设置为incremental mode模式也可获得较短的停顿时间。
   4. 浮动垃圾：由于在应用运行的同时进行垃圾回收，所以有些垃圾可能在垃圾回收进行完成时产生，这样就造成了“Floating Garbage”，这些垃圾需要在下次垃圾回收周期时才能回收掉。所以，并发收集器一般需要20%的预留空间用于这些浮动垃圾。
   5. Concurrent Mode Failure：并发收集器在应用运行时进行收集，所以需要保证堆在垃圾回收的这段时间有足够的空间供程序使用，否则，垃圾回收还未完成，堆空间先满了。这种情况下将会发生“并发模式失败”，此时整个应用将会暂停，进行垃圾回收。
   6. 启动并发收集器：因为并发收集在应用运行时进行收集，所以必须保证收集完成之前有足够的内存空间供程序使用，否则会出现“Concurrent Mode Failure”。通过设置-XX:CMSInitiatingOccupancyFraction=<N>指定还有多少剩余堆时开始执行并发收集
4. 小结
   • 串行处理器：
      --适用情况：数据量比较小（100M左右）；单处理器下并且对响应时间无要求的应用。
      --缺点：只能用于小型应用
   • 并行处理器：
      --适用情况：“对吞吐量有高要求”，多CPU、对应用响应时间无要求的中、大型应用。举例：后台处理、科学计算。
      --缺点：应用响应时间可能较长
   • 并发处理器：
      --适用情况：“对响应时间有高要求”，多CPU、对应用响应时间有较高要求的中、大型应用。举例：Web服务器/应用服务器、电信交换、集成开发环境。

1. 堆大小设置
   JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统下，一般限制在1.5G~2G；64为操作系统对内存无限制。我在Windows Server 2003 系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m。
   典型设置：
   • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m：设置JVM最大可用内存为3550M。
-Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn2g：设置年轻代大小为2G。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。

   • java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
     -XX:MaxPermSize=16m:设置持久代大小为16m。
     -XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
2. 回收器选择
   JVM给了三种选择：串行收集器、并行收集器、并发收集器，但是串行收集器只适用于小数据量的情况，所以这里的选择主要针对并行收集器和并发收集器。默认情况下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后，JVM会根据当前系统配置进行判断。
   1. 吞吐量优先的并行收集器
      如上文所述，并行收集器主要以到达一定的吞吐量为目标，适用于科学技术和后台处理等。
      典型配置：
      • java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。
-XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。

      • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。

      • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。

      • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
        -XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。
        
   2. 响应时间优先的并发收集器
      如上文所述，并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。
      典型配置：
      • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。
-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。
      • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
        -XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片
        
3. 辅助信息
   JVM提供了大量命令行参数，打印信息，供调试使用。主要有以下一些：
   • -XX:+PrintGC
     输出形式：[GC 118250K->113543K(130112K), 0.0094143 secs]

                     [Full GC 121376K->10414K(130112K), 0.0650971 secs]

   • -XX:+PrintGCDetails
     输出形式：[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]

                     [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]

   • -XX:+PrintGCTimeStamps -XX:+PrintGC：PrintGCTimeStamps可与上面两个混合使用
     输出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
     
   • -XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前，程序未中断的执行时间。可与上面混合使用
     输出形式：Application time: 0.5291524 seconds
     
   • -XX:+PrintGCApplicationStoppedTime：打印垃圾回收期间程序暂停的时间。可与上面混合使用
     输出形式：Total time for which application threads were stopped: 0.0468229 seconds
     
   • -XX:PrintHeapAtGC:打印GC前后的详细堆栈信息
     输出形式：
     34.702: [GC {Heap before gc invocations=7:
      def new generation   total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
     eden space 49152K,  99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
     from space 6144K,  55% used [0x221d0000, 0x22527e10, 0x227d0000)
       to   space 6144K,   0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
      tenured generation   total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
     the space 69632K,   3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
      compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
        the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
         ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
         rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
     34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
      def new generation   total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
     eden space 49152K,   0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
       from space 6144K,  55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
       to   space 6144K,   0% used [0x221d0000, 0x221d0000, 0x227d0000)
      tenured generation   total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
     the space 69632K,   4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
      compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
        the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
         ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
         rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
     }
     , 0.0757599 secs]
     
   • -Xloggc:filename:与上面几个配合使用，把相关日志信息记录到文件以便分析。
4. 常见配置汇总
   1. 堆设置
      • -Xms:初始堆大小
      • -Xmx:最大堆大小
      • -XX:NewSize=n:设置年轻代大小
      • -XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4
      • -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5
      • -XX:MaxPermSize=n:设置持久代大小
   2. 收集器设置
      • -XX:+UseSerialGC:设置串行收集器
      • -XX:+UseParallelGC:设置并行收集器
      • -XX:+UseParalledlOldGC:设置并行年老代收集器
      • -XX:+UseConcMarkSweepGC:设置并发收集器
   3. 垃圾回收统计信息
      • -XX:+PrintGC
      • -XX:+PrintGCDetails
      • -XX:+PrintGCTimeStamps
      • -Xloggc:filename
   4. 并行收集器设置
      • -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
      • -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
      • -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
   5. 并发收集器设置
      • -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
      • -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。

1. 年轻代大小选择
   • 响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
   • 吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
2. 年老代大小选择
   • 响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：
     • 并发垃圾收集信息
     • 持久代并发收集次数
     • 传统GC信息
     • 花在年轻代和年老代回收上的时间比例
     减少年轻代和年老代花费的时间，一般会提高应用的效率
     
   • 吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。
3. 较小堆引起的碎片问题
   因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：
   • -XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
   • -XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩

• Java 理论与实践: 垃圾收集简史
• Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning
• Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1
• Hotspot memory management whitepaper
• Java Tuning White Paper
• Diagnosing a Garbage Collection problem
• Java HotSpot VM Options
• A Collection of JVM Options
• Frequently Asked Questions about Garbage Collection in the HotspotTM JavaTM Virtual Machine

项目背景

问题描述

某个大型项目（Use Case用例超过300个），在项目上线后，其Web应用服务器经常宕机。表现为：

1. 应用服务器内存长期不合理占用，内存经常处于高位占用，很难回收到低位；

2. 应用服务器极为不稳定，几乎每两天重新启动一次，有时甚至每天重新启动一次；

3. 应用服务器经常做Full GC(Garbage Collection)，而且时间很长，大约需要30-40秒，应用服务器在做Full GC的时候是不响应客户的交易请求的，非常影响系统性能。

Web应用服务器的物理部署

      一台Unix服务器（4CPU，8G Memory）来部署本Web应用程序；Web应用程序部署在中间件应用服务器上；部署了一个节点（Node），只配置一个应用服务器实例（Instance），没有做Cluster部署。

Web应用服务器启动脚本中的内存参数

可以看出目前生产系统中Web应用服务器的内存分配为3G Memory。

Web应用服务器的重要部署参数

分析

分析方法

内存长期占用并导致系统不稳定一般有两种可能：

1. 对象被大量创建而且被缓存，在旧的对象释放前又有大量新的对象被创建使得内存长期高位占用。

• 表现为：内存不断被消耗、在高位时也很难回归到低位，有大量的对象在不断的创建，经过很长时间后又被回收。例如：在HttpSession中保存了大量的分页查询数据，而HttpSession的会话超时时间设置过长（例如：1天），那么在旧的对象释放前又有大量新的对象在第二天产生。
• 解决办法：对共享的对象可以采用池机制进行缓存，避免各自创建；缓存的临时对象应该及时释放；另一种办法是扩大系统的内存容量。

2. 另一种情况就是内存泄漏问题

• 表现为：内存回收低位点不断升高（以每次内存回收的最低点连成一条直线，那么它是一条上升线）；内存回收的频率也越来越高，内存占用也越来越高，最终出现"Out of Memory Exception"的系统异常。
• 解决办法：定位那些有内存泄漏的类或对象并修改完善这些类以避免内存泄漏。方法是：经过一段时间的测试、监控，如果某个类的对象数目屡创新高，即使在JVM Full GC后仍然数目降不下来，这些对象基本上是属于内存泄漏的对象了。

问题定位

这里请看5月份 Web应用服务器的内存回收图形：

《注意：5月18日早上10点重新启动了Web服务器，5月20日早上又重新启动了Web服务器。》

• 在Web应用重要部署参数中，我们知道：Session的超时时间为4个小时，我们在监控平台也观测到：在18日晚上10点左右所有的会话都过期了，从图形一中也能看出18日晚上确实系统的内存有回收到40%（就象股票的高位跳水）；
• 从图形一（5月18日）中我们也能看到Full GC回收后的内存占用率走势（红色曲线），上午基本平滑上升到20%（内存占用率），中午开始上升到30%，下午上升到40%
• 从图形二（5月19日）中我们也能看到Full GC回收后的内存占用率走势（红色曲线），上午又上升到了60%，到下午上升到了70%。
• 从黄色曲线（GC花费的时间，以秒为单位），Full GC的频率也在增快，时间耗费也越来越长，在图形一中基本高位在20秒左右，到19日基本都是30-40秒之间了。

 图形一 5月18日


图二

通过上述分析，我们基本定位到了Web应用服务器的内存在高位长期占用的原因了：是内存泄露！并且正是由于这个原因导致系统不稳定、响应客户请求越来越慢的。

解决方法

方法如下：

• 我们从图形二中发现，在8.95(将近9点钟)到9.66（将近9点40）期间有几次Full GC，但是有内存泄漏，从占用率40%上升到50%左右，泄漏了大约10%的内存，约300M；
• 我们在自己搭建的Web应用服务器平台（应用软件版本和生产版本一致）做这一阶段相同的查询交易；表明对同一个黑盒（Web应用）施加同样的刺激（相同的操作过程和查询交易）以期重现现象；
• 我们使用Jprofiler工具对Web应用服务器的内存进行实时监控；
• 做完这些交易后，用户退出系统，并等待Web应用服务器的HttpSession超时（我们这里设置为15分钟）；
• 我们对Web应用服务器做了两次强制性的内存回收操作。

发现如下：

图三

如图三所示，内存经过HttpSession超时后，并强制gc后，仍然有大量的对象没有释放。例如：gov.gdlt.taxcore.comm.security.MenuNode，仍然有807个实例没有释放。

我们继续追溯发现，这些MenuNode首先存放在一个ArrayList对象中，然后发现这个ArrayList对象又是存放在 WHsessionAttrVO对象的Map中，WHsessionAttrVO 对象又是存放在ExternalSessionManager的staic Map中（名称为sessionMap），如图四所示。

图四

我们发现gov.gdlt.taxcore.taxevent.xtgl.comm.WHsessionAttrVO中保存了EJBSessionId信息 (登录用户的唯一标志，由用户id+登录时间戳组成，每天都不同)和一个HashMap，这个HashMap中的内容有：

• ArrayList: 内有MenuTreeNodes（菜单树节点）
• HashMap: 内有操作人员代码信息
• CurrentVersion:当前版本号
• CurrentTime:当前系统时间

WHsessionAttrVO 这个对象的最终存放在ExternalSessionManager的static Map sessionMap中，由于ExternalSessionManager是一个全局的单实例，不会释放，所以它的成员变量sessionMap中的数据也不会释放，而Map中的Key值为EJBSessionId，每天登录的用户EJBSessionId都不同，就造成了每天的登录信息（包括菜单信息）都保存在sessionMap中不会被释放，最终造成了内存的泄漏。

图五

如上图所示：WHsessionAttrsVO对象中除了有一个String对象（内容是EJBSessionId），还有一个HashMap对象。

图六

如上图所示，这个HashMap中的内容主要有menuTreeNodes为key，value为ArrayList的对象和以czrydminfo为key，value为HashMap对象的数据。

图七

如上图所示：menuTreeNodes为key，value为ArrayList对象中包含的对象有许多的MenuNode对象，封装的都是用户的菜单节点。

图八

如上图所示，最顶层（Root）的初始对象为一个ExternalSessionManager对象，其中的一个成员变量为static (静态的)，名称为：sessionMap，这个对象是singleton方式的，全局只有一个。

初步估量

我们从图形一和图形二中可以看出，每天应用服务器损失大约40%的内存，大约1G左右。

从图形四可以看出，当前用户（Id=24400001129）有807个菜单项（每个菜单项为一个MenuNode 对象实例，图形四中的这个实例的size为592 Byte），这些菜单数据和用户基本登录信息（czrydmInfo HashMap）也都存放在WHsessionAttrVO对象中，当前这个WHsessionAttrVO对象的size为457K。

我们做如下估算：

假设平均每天有4千人（估计值，这个数值仅仅是5月19日峰值的1/2左右）登录系统（有重复登录的现象，例如：上午登录一次，中午退出系统，下午登录一次），以平均每人占用200K（估计值，是用户id=24400001129 的Size的1/2左右）来计算，一天泄漏的内存约800M，比较符合目前内存泄漏的情况。当然，这种估计仍然需要经过实践的检验，方法是：当这次发现的内存泄漏问题解决后看系统是否还有其它内存泄漏问题。

ExternalSessionManager类是当初某某软件商设计的用来解决Web服务器负载均衡的模块，这个类主要用来保存客户的基本登录信息（包括会话的EJBSessionId），以维护多个Web服务器之间的会话信息一致。

改进方案有两种：

• 从架构设计方面改进

  实现Web层的负载均衡有很多标准的实现方式。例如：采用负载均衡设备(硬件或软件)来实现。

  如果采用新的Web层的负载均衡方式，那么就可以去掉ExternalSessionManager这个类了。

• 从应用实现方面改进

  保留当前的Web层的负载均衡设计机制，仅仅从应用实现方面解决内存泄漏问题，首先菜单信息不应该保存在ExternalSessionManager中。其次，增加对ExternalSessionManager类中用户会话登录信息的清除，有几种方式可以选择：

  • 被动方式，当HttpSession会话超时（或过期）被Web应用服务器回收时清除相应的ExternalSessionManager中的过期会话登录信息。
  • 主动方式，可以采用任务定时清理每天的过期会话登录信息或线程轮询清理。
  • 采用新的会话登录信息存储方式，ExternalSessionManager的sessionMap中的key值不再以EJBSessionId作为键值，而是以用户id（EJBSessionId的前11位）代替。由于用户id每天都是一样的，所以不会造成内存泄漏。保存得登录信息也不再包含菜单节点信息，而只是登录基本信息。最多也只是保存整个系统所有的用户id及其基本登录信息（大约每个用户的登录信息只有1.5K左右，而目前这个系统的营业网点用户为1万左右，所以大约只占用Web服务器15M内存）。

采用的方案：某某软件商采用了新的会话登录信息存贮方案，即:ExternalSessionManager的成员变量sessionMap中不再保存用户菜单信息，只保存基本的登录信息；存储方式采用用户id（11位）作为键值（key）来保留用户基本登录信息。

基本分析：由于基本登录信息只有1K左右，而目前内网登录的用户总数也只有8887个，所以只保存了大约10M-15M的信息在内存，占用量很小，并且不会有内存泄漏。用户菜单信息保存在session中，如果用户退出时点击logout页面，那么应用服务器可以很快地释放这部分内存；如果用户直接关闭窗口，那么保存在session中的菜单信息只有等会话超时后才会由系统清除并回收内存。

监控状况：

图九

如图九所示，ExternalSessionManager中只保留了简单的登录信息（Map中保存了WHsessionAttrVO对象），包括：当前版本(currentversion)，操作人员代码基本信息（czrydmInfo），当前时间（currenttime）。

图十

如图十所示，这个登录用户的基本信息只有1368 bytes，大约1.3K

图十一

如图十一所示，一共有两个用户（相同的用户id）登录系统，当一个用户使用logout页面退出时，保留在session中的菜单信息(MenuNode)立刻释放了，所以Difference一栏减少了806个菜单项。

图十二

如图十二所示，当另外一个会话超时后，应用服务器回收了整个会话的菜单信息（MenuNode），图上已经没有MenuNode对象了。并且由于是同一个用户登录，所以保留在ExternalSessionManager成员变量sessionMap中的对象WHsessionAttrVO只有一个 (id=24400001129)，而没有产生多个，没有因为多次登录而产生多个对象的后果，避免了内存泄漏问题的出现，解决了前期定位的内存泄漏问题。

图十三

如图十三所示，经过gc内存回收后，发现内存回收比较稳定，基本都回收到了最低点，也证明了内存没有泄露。

结论与建议：从测试情况看，解决了前期定位的内存泄漏问题。

生产系统实施后的监控与分析

经过调优后，我们发现：在2005年6月2日晚9点40左右重新部署、启动了Web应用服务器（采用了新的调优方案）。经过几天的监控运行，发现Web应用服务器目前运行基本稳定，目前没有出现新的内存泄漏问题，下列图示说明了这一点

图十四 2005年6月2日

如图十四所示，6月2日晚21.7（21点42分）重新启动应用服务器，内存占用很少，大约为15%（请看红色曲线），每次GC消耗的时间也很短，大约在5秒以内（请看黄色曲线）。

图十五 2005年6月3日周五

如图十五所示，在6月3日周五的整个工作日内，内存的回收基本到位，回收位置控制在20%-30%之间，也就是在600M-900M之间（请看红色曲线的最低点），始终可以回收2G的内存供应用程序使用，每次GC的时间最高不超过20秒，Full GC平均在10秒左右，时间消耗比较短（请看黄色曲线）。

图十六2005年6月5日周日

如图十六所示，在周日休息日期间，Web应用服务器全天只做了大约4次Full GC（黄色曲线中的小山峰），时间都在10秒以内；大的Full GC后，内存只占用10%，内存回收很彻底。

图十七 2005年6月6日周一

如图十七所示，在周一工作日期间，内存回收还是不错的，基本可以回收到30%（见红色曲线的最低点），即：占用900M内存空间，剩余2G的内存空间；Full GC的时间大部分控制在20秒以内，平均15秒（见黄色曲线）。

图十八 2005年6月7日周二

如图十八所示，在6月7日周二早上，大约8:30左右，Web应用服务器作了一次Full GC，用了10秒的时间，把内存回收到了10%的位置，为后续的使用腾出了90%的内存空间。内存回收仍然比较彻底，说明基本没有内存泄漏问题。

经过这几天的监控分析，我们可以看出：

• Web应用服务器的内存使用已经比较合理，内存在工作日的占用在20%至30%之间，约1G的内存占用，有2G的内存空间富裕；而在空闲时间（周日，每天的凌晨等）内存可以回收到10%，有90%的内存空间富裕；
• Web应用服务器的Full GC的次数明显减少了并且每次Full GC占用的时间也很少，基本控制在10-20秒之间，有的甚至在10秒以内，明显改善了内网应用服务器内存的使用；
• 从6月2日重新部署之后，Web应用服务器没有出现宕机重启的现象。

总结

 通过本文，我们可以看到，内存的泄露将会导致服务器的宕机，系统性能就更别说了。对于系统内存泄露问题应该从服务器GC日志方面进行早诊断，使用工具早确认并提出解决方案，排除内存泄露问题，提高系统性能，以规避项目风险。

class Example1 extends Thread {
            boolean stop=false;
            public static void main( String args[] ) throws Exception {
            Example1 thread = new Example1();
            System.out.println( "Starting thread..." );
            thread.start();
            Thread.sleep( 3000 );
            System.out.println( "Interrupting thread..." );
            thread.interrupt();
            Thread.sleep( 3000 );
            System.out.println("Stopping application..." );
            //System.exit(0);
            }
            public void run() {
            while(!stop){
            System.out.println( "Thread is running..." );
            long time = System.currentTimeMillis();
            while((System.currentTimeMillis()-time < 1000)) {
            }
            }
            System.out.println("Thread exiting under request..." );
            }
            }

如果你运行了Listing A中的代码，你将在控制台看到以下输出：

Starting thread...

Thread is running...

Thread is running...

Thread is running...

Interrupting thread...

Thread is running...

Thread is running...

Thread is running...

Stopping application...

Thread is running...

Thread is running...

Thread is running...
...............................
甚至，在Thread.interrupt()被调用后，线程仍然继续运行。

真正地中断一个线程

    中断线程最好的，最受推荐的方式是，使用共享变量（shared variable）发出信号，告诉线程必须停止正在运行的任务。线程必须周期性的核查这一变量（尤其在冗余操作期间），然后有秩序地中止任务。Listing B描述了这一方式。

Listing B
class Example2 extends Thread {

  volatile boolean stop = false;

  public static void main( String args[] ) throws Exception {

    Example2 thread = new Example2();

   System.out.println( "Starting thread..." );

   thread.start();

   Thread.sleep( 3000 );

   System.out.println( "Asking thread to stop..." );

   thread.stop = true;

   Thread.sleep( 3000 );

   System.out.println( "Stopping application..." );

   //System.exit( 0 );

  }

  public void run() {

    while ( !stop ) {

     System.out.println( "Thread is running..." );

      long time = System.currentTimeMillis();

      while ( (System.currentTimeMillis()-time < 1000) && (!stop) ) {

      }

    }

   System.out.println( "Thread exiting under request..." );

  }

}
 
运行Listing B中的代码将产生如下输出（注意线程是如何有秩序的退出的）

Starting thread...

Thread is running...

Thread is running...

Thread is running...

Asking thread to stop...

Thread exiting under request...

Stopping application...

   虽然该方法要求一些编码，但并不难实现。同时，它给予线程机会进行必要的清理工作，这在任何一个多线程应用程序中都是绝对需要的。请确认将共享变量定义成volatile 类型或将对它的一切访问封入同步的块/方法（synchronized blocks/methods）中。

到目前为止一切顺利!但是，当线程等待某些事件发生而被阻塞，又会发生什么？当然，如果线程被阻塞，它便不能核查共享变量，也就不能停止。这在许多情况下会发生，例如调用Object.wait()、ServerSocket.accept()和DatagramSocket.receive()时，这里仅举出一些。

他们都可能永久的阻塞线程。即使发生超时，在超时期满之前持续等待也是不可行和不适当的，所以，要使用某种机制使得线程更早地退出被阻塞的状态。

很不幸运，不存在这样一种机制对所有的情况都适用，但是，根据情况不同却可以使用特定的技术。在下面的环节，我将解答一下最普遍的例子。

使用Thread.interrupt()中断线程

  正如Listing A中所描述的，Thread.interrupt()方法不会中断一个正在运行的线程。这一方法实际上完成的是，在线程受到阻塞时抛出一个中断信号，这样线程就得以退出阻塞的状态。更确切的说，如果线程被Object.wait, Thread.join和Thread.sleep三种方法之一阻塞，那么，它将接收到一个中断异常（InterruptedException），从而提早地终结被阻塞状态。

    因此，如果线程被上述几种方法阻塞，正确的停止线程方式是设置共享变量，并调用interrupt()（注意变量应该先设置）。如果线程没有被阻塞，这时调用interrupt()将不起作用；否则，线程就将得到异常（该线程必须事先预备好处理此状况），接着逃离阻塞状态。在任何一种情况中，最后线程都将检查共享变量然后再停止。Listing C这个示例描述了该技术。

Listing C
class Example3 extends Thread {

  volatile boolean stop = false;

  public static void main( String args[] ) throws Exception {

   Example3 thread = new Example3();

   System.out.println( "Starting thread..." );

   thread.start();

   Thread.sleep( 3000 );

   System.out.println( "Asking thread to stop..." );

   thread.stop = true;//如果线程阻塞，将不会检查此变量

   thread.interrupt();

   Thread.sleep( 3000 );

   System.out.println( "Stopping application..." );

   //System.exit( 0 );

  }

  public void run() {

    while ( !stop ) {

     System.out.println( "Thread running..." );

      try {

      Thread.sleep( 1000 );

      } catch ( InterruptedException e ) {

      System.out.println( "Thread interrupted..." );

      }

    }

   System.out.println( "Thread exiting under request..." );

  }

}

一旦Listing C中的Thread.interrupt()被调用，线程便收到一个异常，于是逃离了阻塞状态并确定应该停止。运行以上代码将得到下面的输出：

Starting thread...

Thread running...

Thread running...

Thread running...

Asking thread to stop...

Thread interrupted...

Thread exiting under request...

Stopping application...


中断I/O操作
    然而，如果线程在I/O操作进行时被阻塞，又会如何？I/O操作可以阻塞线程一段相当长的时间，特别是牵扯到网络应用时。例如，服务器可能需要等待一个请求（request），又或者，一个网络应用程序可能要等待远端主机的响应。

如果你正使用通道（channels）（这是在Java 1.4中引入的新的I/O API），那么被阻塞的线程将收到一个ClosedByInterruptException异常。如果情况是这样，其代码的逻辑和第三个例子中的是一样的，只是异常不同而已。

但是，你可能正使用Java1.0之前就存在的传统的I/O，而且要求更多的工作。既然这样，Thread.interrupt()将不起作用，因为线程将不会退出被阻塞状态。Listing D描述了这一行为。尽管interrupt()被调用，线程也不会退出被阻塞状态

Listing D
import java.io.*;

class Example4 extends Thread {

  public static void main( String args[] ) throws Exception {

    Example4 thread = new Example4();

   System.out.println( "Starting thread..." );

   thread.start();

   Thread.sleep( 3000 );

   System.out.println( "Interrupting thread..." );

   thread.interrupt();

   Thread.sleep( 3000 );

   System.out.println( "Stopping application..." );

   //System.exit( 0 );

  }

  public void run() {

   ServerSocket socket;

    try {

      socket = new ServerSocket(7856);

    } catch ( IOException e ) {

     System.out.println( "Could not create the socket..." );

      return;

    }

    while ( true ) {

     System.out.println( "Waiting for connection..." );

      try {

       Socket sock = socket.accept();

      } catch ( IOException e ) {

      System.out.println( "accept() failed or interrupted..." );

      }

    }

  }

}


   很幸运，Java平台为这种情形提供了一项解决方案，即调用阻塞该线程的套接字的close()方法。在这种情形下，如果线程被I/O操作阻塞，该线程将接收到一个SocketException异常，这与使用interrupt()方法引起一个InterruptedException异常被抛出非常相似。

唯一要说明的是，必须存在socket的引用（reference），只有这样close()方法才能被调用。这意味着socket对象必须被共享。Listing E描述了这一情形。运行逻辑和以前的示例是相同的。

Listing E
import java.net.*;
import java.io.*;
class Example5 extends Thread {
  volatile boolean stop = false;
  volatile ServerSocket socket;
  public static void main( String args[] ) throws Exception {
    Example5 thread = new Example5();
   System.out.println( "Starting thread..." );
   thread.start();
   Thread.sleep( 3000 );
   System.out.println( "Asking thread to stop..." );
   thread.stop = true;
   thread.socket.close();
   Thread.sleep( 3000 );
   System.out.println( "Stopping application..." );
   //System.exit( 0 );
  }
  public void run() {
    try {
      socket = new ServerSocket(7856);
    } catch ( IOException e ) {
     System.out.println( "Could not create the socket..." );
      return;
    }
    while ( !stop ) {
     System.out.println( "Waiting for connection..." );
      try {
       Socket sock = socket.accept();
      } catch ( IOException e ) {
      System.out.println( "accept() failed or interrupted..." );
      }
    }
   System.out.println( "Thread exiting under request..." );
  }
}
以下是运行Listing E中代码后的输出：

Starting thread...

Waiting for connection...

Asking thread to stop...

accept() failed or interrupted...

Thread exiting under request...

Stopping application...

多线程是一个强大的工具，然而它正呈现出一系列难题。其中之一是如何中断一个正在运行的线程。如果恰当地实现，使用上述技术中断线程将比使用Java平台上已经提供的内嵌操作更为简单。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

-------------------------------------------

 ---------------------------------------------

------------------------------------------

For all those out there using Spring together with Struts, i created a small howTo regarding automatic generation of relevant files, especially the boring action-servlet-xml file which must be in synch with your struts-config.xml, at least for all Struts actions which should be injected by Spring.

Lets start with the Action class:

/**

            * Action to delete a Client

            * Date: 09.02.2005

            * Time: 15:29:15

            *

            * @author Logemann - Logentis e.K. (ml@logentis.de)

            * @version $Id$

            * @struts.action path="clientDelete" validate="false"

            *            type="org.springframework.web.struts.DelegatingActionProxy"

            *            name="emptyform"

            * @struts.action-forward name="back" 

            *             path="/clientManager.html" redirect="true"

            * @spring.bean name="clientDelete"

            */

            public class ClientDeleteAction extends Action {

            

            
    ClientManager clientManagerService;
            

            

            
    /**

            

            * Spring injection

            

            *

            

            * @param clientManagerService clientManagerService

            

            * @spring.property ref="clientManagerService"

            

            */

            

            public void setClientManagerService(ClientManager clientManagerService) {

            

            this.clientManagerService = clientManagerService;

            

            }

            

            [..]

            

            
            

With this tags, the ant build target outlined below will create a struts-config.xml and the necessary action-servlet.xml needed by Spring. Lets see how the target looks:

Be sure to modify the classpath definition and the destDir values of springdoclet and webdoclet to suit your needs. Right now the Spring task only searches for Actions in order to create action-servlet.xml, if you also want to create your normal service beans like ClientManagerService, you should create another springdoclet task and output things to applicationContext.xml if you like.

But this is mostly users choice, as you know, Spring supports from one to many bean definition files and its up to you how you want to have your spring xml world.

This will be created when you run the mentioned target:

(action-servlet.xml)

(struts-config.xml)

<!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">

<struts-config>

<!-- ========== Data Sources Definitions =================================== -->
<!--
Define your Struts data sources in a file called struts-data-sources.xml and place
it in your merge directory.
-->

<!-- ========== Form Bean Definitions =================================== -->
<form-beans>

<!--
If you have non XDoclet forms, define them in a file called struts-forms.xml and
place it in your merge directory.
-->
</form-beans>

<!-- ========== Global Exceptions Definitions =================================== -->
<!--
Define your exceptions in a file called global-exceptions.xml and place
it in your merge directory.
-->

<!-- ========== Global Forward Definitions =================================== -->
<!--
Define your forwards in a file called global-forwards.xml and place
it in your merge directory.
-->

<!-- ========== Action Mapping Definitions =================================== -->
<action-mappings>
<action
path="clientDelete"
type="org.springframework.web.struts.DelegatingActionProxy"
name="emptyform"
scope="request"
unknown="false"
validate="false"
>
<forward
name="back"
path="/clientManager.html"
redirect="true"
/>
</action>

<!-- If you have non XDoclet actions, define them in a file called struts-actions.xml and place it in your merge directory. -->
</action-mappings>

<!-- Define your Struts controller in a file called struts-controller.xml and place it in your merge directory. -->

<!-- Define your Struts message-resources in a file called struts-message-resources.xml and place it in your merge directory. -->

<!-- Define your Struts plugins in a file called struts-plugins.xml and place it in your merge directory. -->

• Application startup and shutdown
• Session creation and invalidation

As their names suggest, application startup event occurs when your web application is first loaded and started by the Servlet container and application shutdown event occurs when the web application is shutdown.

Session creation event occurs everytime a new session is created on the server and similarly session invalidation event occurs everytime a session is invalidated. To make use of these web application events and to do something useful you'll have to create and make use of special "listener" classes. From here onwards, we'll look at what these listener classes are how you can use them.

Listener Classes :
These are simple Java classes which implement one of the two following interfaces :

• javax.servlet.ServletContextListener
• javax.servlet.http.HttpSessionListener

If you want your class to listen for application startup and shutdown events then implement ServletContextListener interface. If you want your class to listen for session creation and invalidation events then implement HttpSessionListener interface.

Let's see what are the different methods of these interfaces which you'll have to implement.

ServletContextListener :
This interface contains two methods :

• public void contextInitialized(ServletContextEvent sce);
• public void contextDestroyed(ServletContextEvent sce);

Once you implement any interface you have to implement all of it's methods. So you if you want to make use of application startup and shutdown events, then create a Java class and implement ServletContextListener interface. An example of such a class is as follows :

/*

File : ApplicationWatch.java

*/



import javax.servlet.ServletContextListener;

import javax.servlet.ServletContextEvent;



public class ApplicationWatch implements ServletContextListener	{



public static long applicationInitialized =	0L;



/* Application Startup Event */

public void	contextInitialized(ServletContextEvent ce) {

applicationInitialized = System.currentTimeMillis();

}



/* Application Shutdown	Event */

public void	contextDestroyed(ServletContextEvent ce) {}

}

In the code above, a Java class; ApplicationWatch, implements ServletContextListener interface. It implement both of it's methods but it really uses only one of them and the second method's body remains empty. This class notes down the time of application startup in a public static variable which can be called from other application classes to know what was the last time this application was started.

I'll explain how to tell the application server that we have this listener class and we want to be told of these application events in a moment, but first let's see what are the different methods of HttpSessionListener interface.

HttpSessionListener :
This interface also contains just two methods, for session creation and invalidation events respectively :

• public void sessionCreated(HttpSessionEvent se);
• public void sessionDestroyed(HttpSessionEvent se);

Like what we did in the case of ApplicationWatch above, we'll have to create a Java class and implement HttpSessionListener interface. An example of such a class is as follows :

/*

File : SessionCounter.java

*/



import javax.servlet.http.HttpSessionListener;

import javax.servlet.http.HttpSessionEvent;



public class SessionCounter	implements HttpSessionListener {



private	static int activeSessions =	0;



/* Session Creation	Event */

public void	sessionCreated(HttpSessionEvent	se)	{

activeSessions++;

}



/* Session Invalidation	Event */

public void	sessionDestroyed(HttpSessionEvent se) {

if(activeSessions >	0)

activeSessions--;

}



public static int getActiveSessions() {

return activeSessions;

}

}

In the code above, SessionCounter class implements HttpSessionListener to count the number of active sessions. We will learn more about counting active users in a separate article in more detail.

Ok, we have learned what are web application events, what interfaces are available to us and have also seen examples of classes implementing those interfaces. Let's see how to tell the application server about these listener classes.

Web.xml :
We do that by putting classpath of these classes in /WEB-INF/web.xml file under special <listener> tags. An example of such a web.xml file is given below :

<!-- Web.xml -->

<?xml version="1.0" encoding="ISO-8859-1"?>



<!DOCTYPE web-app

PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"

"http://java.sun.com/j2ee/dtds/web-app_2.3.dtd">



<web-app>



<!-- Listeners -->

<listener>

<listener-class>

com.stardeveloper.web.listener.SessionCounter

</listener-class>

</listener>

<listener>

<listener-class>

com.stardeveloper.web.listener.ApplicationWatch

</listener-class>

</listener>



</web-app>

As shown above it is quite easy to declare listener classes in web.xml files. Now every time the server starts or shutdown, a session is created or destroyed, your classes will be told as their specific event methods will be called. It is that simple!

Summary :
In this article we learned what are web application events and how we can make use of these events by creating special "listener" classes. We then created two classes which implemented ServletContextListener and HttpSessionListener interfaces respectively. We also learned how to declare these listener classes in web.xml file by using special <listener> and <listener-class> tags.

EasyMock 是一套通过简单的方法对于指定的接口或类生成 Mock 对象的类库，它能利用对接口或类的模拟来辅助单元测试。本文将对 EasyMock 的功能和原理进行介绍，并通过示例来说明如何使用 EasyMock 进行单元测试。

Mock 方法是单元测试中常见的一种技术，它的主要作用是模拟一些在应用中不容易构造或者比较复杂的对象，从而把测试与测试边界以外的对象隔离开。

编写自定义的 Mock 对象需要额外的编码工作，同时也可能引入错误。EasyMock 提供了根据指定接口动态构建 Mock 对象的方法，避免了手工编写 Mock 对象。本文将向您展示如何使用 EasyMock 进行单元测试，并对 EasyMock 的原理进行分析。

1．Mock 对象与 EasyMock 简介

单元测试与 Mock 方法

单元测试是对应用中的某一个模块的功能进行验证。在单元测试中，我们常遇到的问题是应用中其它的协同模块尚未开发完成，或者被测试模块需要和一些不容易构造、比较复杂的对象进行交互。另外，由于不能肯定其它模块的正确性，我们也无法确定测试中发现的问题是由哪个模块引起的。

Mock 对象能够模拟其它协同模块的行为，被测试模块通过与 Mock 对象协作，可以获得一个孤立的测试环境。此外，使用 Mock 对象还可以模拟在应用中不容易构造（如 HttpServletRequest 必须在 Servlet 容器中才能构造出来）和比较复杂的对象（如 JDBC 中的 ResultSet 对象），从而使测试顺利进行。

EasyMock 简介

手动的构造 Mock 对象会给开发人员带来额外的编码量，而且这些为创建 Mock 对象而编写的代码很有可能引入错误。目前，有许多开源项目对动态构建 Mock 对象提供了支持，这些项目能够根据现有的接口或类动态生成，这样不仅能避免额外的编码工作，同时也降低了引入错误的可能。

EasyMock 是一套用于通过简单的方法对于给定的接口生成 Mock 对象的类库。它提供对接口的模拟，能够通过录制、回放、检查三步来完成大体的测试过程，可以验证方法的调用种类、次数、顺序，可以令 Mock 对象返回指定的值或抛出指定异常。通过 EasyMock，我们可以方便的构造 Mock 对象从而使单元测试顺利进行。

安装 EasyMock

EasyMock 是采用 MIT license 的一个开源项目，您可以在 Sourceforge 上下载到相关的 zip 文件。目前您可以下载的 EasyMock 最新版本是2.3，它需要运行在 Java 5.0 平台上。如果您的应用运行在 Java 1.3 或 1.4 平台上，您可以选择 EasyMock1.2。在解压缩 zip 包后，您可以找到 easymock.jar 这个文件。如果您使用 Eclipse 作为 IDE，把 easymock.jar 添加到项目的 Libraries 里就可以使用了（如下图所示）。此外，由于我们的测试用例运行在 JUnit 环境中，因此您还需要 JUnit.jar（版本3.8.1以上）。

回页首

2．使用 EasyMock 进行单元测试

通过 EasyMock，我们可以为指定的接口动态的创建 Mock 对象，并利用 Mock 对象来模拟协同模块或是领域对象，从而使单元测试顺利进行。这个过程大致可以划分为以下几个步骤：

• 使用 EasyMock 生成 Mock 对象；
• 设定 Mock 对象的预期行为和输出；
• 将 Mock 对象切换到 Replay 状态；
• 调用 Mock 对象方法进行单元测试；
• 对 Mock 对象的行为进行验证。

接下来，我们将对以上的几个步骤逐一进行说明。除了以上的基本步骤外，EasyMock 还对特殊的 Mock 对象类型、特定的参数匹配方式等功能提供了支持，我们将在之后的章节中进行说明。

使用 EasyMock 生成 Mock 对象

根据指定的接口或类，EasyMock 能够动态的创建 Mock 对象（EasyMock 默认只支持为接口生成 Mock 对象，如果需要为类生成 Mock 对象，在 EasyMock 的主页上有扩展包可以实现此功能），我们以 ResultSet 接口为例说明EasyMock的功能。java.sql.ResultSet 是每一个 Java 开发人员都非常熟悉的接口：

                

            public interface java.sql.ResultSet {

            ......

            public abstract java.lang.String getString(int arg0) throws java.sql.SQLException;

            public abstract double getDouble(int arg0) throws java.sql.SQLException;

            ......

            }

            

通常，构建一个真实的 RecordSet 对象需要经过一个复杂的过程：在开发过程中，开发人员通常会编写一个 DBUtility 类来获取数据库连接 Connection，并利用 Connection 创建一个 Statement。执行一个 Statement 可以获取到一个或多个 ResultSet 对象。这样的构造过程复杂并且依赖于数据库的正确运行。数据库或是数据库交互模块出现问题，都会影响单元测试的结果。

我们可以使用 EasyMock 动态构建 ResultSet 接口的 Mock 对象来解决这个问题。一些简单的测试用例只需要一个 Mock 对象，这时，我们可以用以下的方法来创建 Mock 对象：

ResultSet mockResultSet = createMock(ResultSet.class);

其中 createMock 是 org.easymock.EasyMock 类所提供的静态方法，你可以通过 static import 将其引入（注：static import 是 java 5.0 所提供的新特性）。

如果需要在相对复杂的测试用例中使用多个 Mock 对象，EasyMock 提供了另外一种生成和管理 Mock 对象的机制：

IMocksControl control = EasyMock.createControl(); java.sql.Connection mockConnection = control.createMock(Connection.class); java.sql.Statement mockStatement = control.createMock(Statement.class); java.sql.ResultSet mockResultSet = control.createMock(ResultSet.class);

EasyMock 类的 createControl 方法能创建一个接口 IMocksControl 的对象，该对象能创建并管理多个 Mock 对象。如果需要在测试中使用多个 Mock 对象，我们推荐您使用这一机制，因为它在多个 Mock 对象的管理上提供了相对便捷的方法。

如果您要模拟的是一个具体类而非接口，那么您需要下载扩展包 EasyMock Class Extension 2.2.2。在对具体类进行模拟时，您只要用 org.easymock.classextension.EasyMock 类中的静态方法代替 org.easymock.EasyMock 类中的静态方法即可。

设定 Mock 对象的预期行为和输出

在一个完整的测试过程中，一个 Mock 对象将会经历两个状态：Record 状态和 Replay 状态。Mock 对象一经创建，它的状态就被置为 Record。在 Record 状态，用户可以设定 Mock 对象的预期行为和输出，这些对象行为被录制下来，保存在 Mock 对象中。

添加 Mock 对象行为的过程通常可以分为以下3步：

• 对 Mock 对象的特定方法作出调用；
• 通过 org.easymock.EasyMock 提供的静态方法 expectLastCall 获取上一次方法调用所对应的 IExpectationSetters 实例；
• 通过 IExpectationSetters 实例设定 Mock 对象的预期输出。

设定预期返回值

Mock 对象的行为可以简单的理解为 Mock 对象方法的调用和方法调用所产生的输出。在 EasyMock 2.3 中，对 Mock 对象行为的添加和设置是通过接口 IExpectationSetters 来实现的。Mock 对象方法的调用可能产生两种类型的输出：（1）产生返回值；（2）抛出异常。接口 IExpectationSetters 提供了多种设定预期输出的方法，其中和设定返回值相对应的是 andReturn 方法：

IExpectationSetters<T> andReturn(T value);

我们仍然用 ResultSet 接口的 Mock 对象为例，如果希望方法 mockResult.getString(1) 的返回值为 "My return value"，那么你可以使用以下的语句：

mockResultSet.getString(1); expectLastCall().andReturn("My return value");

以上的语句表示 mockResultSet 的 getString 方法被调用一次，这次调用的返回值是 "My return value"。有时，我们希望某个方法的调用总是返回一个相同的值，为了避免每次调用都为 Mock 对象的行为进行一次设定，我们可以用设置默认返回值的方法：

void andStubReturn(Object value);

假设我们创建了 Statement 和 ResultSet 接口的 Mock 对象 mockStatement 和 mockResultSet，在测试过程中，我们希望 mockStatement 对象的 executeQuery 方法总是返回 mockResultSet，我们可以使用如下的语句

mockStatement.executeQuery("SELECT * FROM sales_order_table"); expectLastCall().andStubReturn(mockResultSet);

EasyMock 在对参数值进行匹配时，默认采用 Object.equals() 方法。因此，如果我们以 "select * from sales_order_table" 作为参数，预期方法将不会被调用。如果您希望上例中的 SQL 语句能不区分大小写，可以用特殊的参数匹配器来解决这个问题，我们将在 "在 EasyMock 中使用参数匹配器" 一章对此进行说明。

设定预期异常抛出

对象行为的预期输出除了可能是返回值外，还有可能是抛出异常。IExpectationSetters 提供了设定预期抛出异常的方法：

IExpectationSetters<T> andThrow(Throwable throwable);

和设定默认返回值类似，IExpectationSetters 接口也提供了设定抛出默认异常的函数：

void andStubThrow(Throwable throwable);

设定预期方法调用次数

通过以上的函数，您可以对 Mock 对象特定行为的预期输出进行设定。除了对预期输出进行设定，IExpectationSetters 接口还允许用户对方法的调用次数作出限制。在 IExpectationSetters 所提供的这一类方法中，常用的一种是 times 方法：

IExpectationSetters<T>times(int count);

该方法可以 Mock 对象方法的调用次数进行确切的设定。假设我们希望 mockResultSet 的 getString 方法在测试过程中被调用3次，期间的返回值都是 "My return value"，我们可以用如下语句：

mockResultSet.getString(1); expectLastCall().andReturn("My return value").times(3);

注意到 andReturn 和 andThrow 方法的返回值依然是一个 IExpectationSetters 实例，因此我们可以在此基础上继续调用 times 方法。

除了设定确定的调用次数，IExpectationSetters 还提供了另外几种设定非准确调用次数的方法：
times(int minTimes, int maxTimes)：该方法最少被调用 minTimes 次，最多被调用 maxTimes 次。
atLeastOnce()：该方法至少被调用一次。
anyTimes()：该方法可以被调用任意次。

某些方法的返回值类型是 void，对于这一类方法，我们无需设定返回值，只要设置调用次数就可以了。以 ResultSet 接口的 close 方法为例，假设在测试过程中，该方法被调用3至5次：

mockResultSet.close(); expectLastCall().times(3, 5);

为了简化书写，EasyMock 还提供了另一种设定 Mock 对象行为的语句模式。对于上例，您还可以将它写成：

expect(mockResult.close()).times(3, 5);

这个语句和上例中的语句功能是完全相同的。

将 Mock 对象切换到 Replay 状态

在生成 Mock 对象和设定 Mock 对象行为两个阶段，Mock 对象的状态都是 Record 。在这个阶段，Mock 对象会记录用户对预期行为和输出的设定。

在使用 Mock 对象进行实际的测试前，我们需要将 Mock 对象的状态切换为 Replay。在 Replay 状态，Mock 对象能够根据设定对特定的方法调用作出预期的响应。将 Mock 对象切换成 Replay 状态有两种方式，您需要根据 Mock 对象的生成方式进行选择。如果 Mock 对象是通过 org.easymock.EasyMock 类提供的静态方法 createMock 生成的（第1节中介绍的第一种 Mock 对象生成方法），那么 EasyMock 类提供了相应的 replay 方法用于将 Mock 对象切换为 Replay 状态：

replay(mockResultSet);

如果 Mock 对象是通过 IMocksControl 接口提供的 createMock 方法生成的（第1节中介绍的第二种Mock对象生成方法），那么您依旧可以通过 IMocksControl 接口对它所创建的所有 Mock 对象进行切换：

control.replay();

以上的语句能将在第1节中生成的 mockConnection、mockStatement 和 mockResultSet 等3个 Mock 对象都切换成 Replay 状态。

调用 Mock 对象方法进行单元测试

为了更好的说明 EasyMock 的功能，我们引入 src.zip 中的示例来解释 Mock 对象在实际测试阶段的作用。其中所有的示例代码都可以在 src.zip 中找到。如果您使用的 IDE 是 Eclipse，在导入 src.zip 之后您可以看到 Workspace 中增加的 project（如下图所示）。

下面是示例代码中的一个接口 SalesOrder，它的实现类 SalesOrderImpl 的主要功能是从数据库中读取一个 Sales Order 的 Region 和 Total Price，并根据读取的数据计算该 Sales Order 的 Price Level（完整的实现代码都可以在 src.zip 中找到）：

                

            public interface SalesOrder

            {

            ……

            public void loadDataFromDB(ResultSet resultSet) throws SQLException;	

            public String getPriceLevel();

            }

            

其实现类 SalesOrderImpl 中对 loadDataFromDB 的实现如下：

                

            public class SalesOrderImpl implements SalesOrder

            {

            ......

            public void loadDataFromDB(ResultSet resultSet) throws SQLException

            {

            orderNumber = resultSet.getString(1);

            region = resultSet.getString(2);

            totalPrice = resultSet.getDouble(3);

            }

            ......

            }

            

方法 loadDataFromDB 读取了 ResultSet 对象包含的数据。当我们将之前定义的 Mock 对象调整为 Replay 状态，并将该对象作为参数传入，那么 Mock 对象的方法将会返回预先定义的预期返回值。完整的 TestCase 如下：

                

            public class SalesOrderTestCase extends TestCase {

            public void testSalesOrder() {

            IMocksControl control = EasyMock.createControl();

            ......

            ResultSet mockResultSet = control.createMock(ResultSet.class);

            try {

            ......

            mockResultSet.next();

            expectLastCall().andReturn(true).times(3);

            expectLastCall().andReturn(false).times(1);

            mockResultSet.getString(1);

            expectLastCall().andReturn("DEMO_ORDER_001").times(1);

            expectLastCall().andReturn("DEMO_ORDER_002").times(1);

            expectLastCall().andReturn("DEMO_ORDER_003").times(1);

            mockResultSet.getString(2);

            expectLastCall().andReturn("Asia Pacific").times(1);

            expectLastCall().andReturn("Europe").times(1);

            expectLastCall().andReturn("America").times(1);

            mockResultSet.getDouble(3);

            expectLastCall().andReturn(350.0).times(1);

            expectLastCall().andReturn(1350.0).times(1);

            expectLastCall().andReturn(5350.0).times(1);

            control.replay();

            ......

            int i = 0;

            String[] priceLevels = { "Level_A", "Level_C", "Level_E" };

            while (mockResultSet.next()) {

            SalesOrder order = new SalesOrderImpl();

            order.loadDataFromDB(mockResultSet);

            assertEquals(order.getPriceLevel(), priceLevels[i]);

            i++;

            }

            control.verify();

            } catch (Exception e) {

            e.printStackTrace();

            }

            }

            }

            

在这个示例中，我们首先创建了 ResultSet 的 Mock 对象 moResultSet，并记录该 Mock 对象的预期行为。之后我们调用了 control.replay()，将 Mock 对象的状态置为 Replay 状态。在实际的测试阶段，Sales Order 对象的 loadDataFromDB 方法调用了 mockResultSet 对象的 getString 和 getDouble 方法读取 mockResultSet 中的数据。Sales Order 对象根据读取的数据计算出 Price Level，并和预期输出进行比较。

对 Mock 对象的行为进行验证

在利用 Mock 对象进行实际的测试过程之后，我们还有一件事情没有做：对 Mock 对象的方法调用的次数进行验证。

为了验证指定的方法调用真的完成了，我们需要调用 verify 方法进行验证。和 replay 方法类似，您需要根据 Mock 对象的生成方式来选用不同的验证方式。如果 Mock 对象是由 org.easymock.EasyMock 类提供的 createMock 静态方法生成的，那么我们同样采用 EasyMock 类的静态方法 verify 进行验证：

verify(mockResultSet);

如果Mock对象是有 IMocksControl 接口所提供的 createMock 方法生成的，那么采用该接口提供的 verify 方法，例如第1节中的 IMocksControl 实例 control：

control.verify();

将对 control 实例所生成的 Mock 对象 mockConnection、mockStatement 和 mockResultSet 等进行验证。如果将上例中 expectLastCall().andReturn(false).times(1) 的预期次数修改为2，在 Eclipse 中将可以看到：

Mock 对象的重用

为了避免生成过多的 Mock 对象，EasyMock 允许对原有 Mock 对象进行重用。要对 Mock 对象重新初始化，我们可以采用 reset 方法。和 replay 和 verify 方法类似，EasyMock 提供了两种 reset 方式：（1）如果 Mock 对象是由 org.easymock.EasyMock 类中的静态方法 createMock 生成的，那么该 Mock 对象的可以用 EasyMock 类的静态方法 reset 重新初始化；（2）如果 Mock 方法是由 IMocksControl 实例的 createMock 方法生成的，那么该 IMocksControl 实例方法 reset 的调用将会把所有该实例创建的 Mock 对象重新初始化。

在重新初始化之后，Mock 对象的状态将被置为 Record 状态。

回页首

3．在 EasyMock 中使用参数匹配器

EasyMock 预定义的参数匹配器

在使用 Mock 对象进行实际的测试过程中，EasyMock 会根据方法名和参数来匹配一个预期方法的调用。EasyMock 对参数的匹配默认使用 equals() 方法进行比较。这可能会引起一些问题。例如在上一章节中创建的mockStatement对象：

mockStatement.executeQuery("SELECT * FROM sales_order_table"); expectLastCall().andStubReturn(mockResultSet);

在实际的调用中，我们可能会遇到 SQL 语句中某些关键字大小写的问题，例如将 SELECT 写成 Select，这时在实际的测试中，EasyMock 所采用的默认匹配器将认为这两个参数不匹配，从而造成 Mock 对象的预期方法不被调用。EasyMock 提供了灵活的参数匹配方式来解决这个问题。如果您对 mockStatement 具体执行的语句并不关注，并希望所有输入的字符串都能匹配这一方法调用，您可以用 org.easymock.EasyMock 类所提供的 anyObject 方法来代替参数中的 SQL 语句：

mockStatement.executeQuery( anyObject() ); expectLastCall().andStubReturn(mockResultSet);

anyObject 方法表示任意输入值都与预期值相匹配。除了 anyObject 以外，EasyMock还提供了多个预先定义的参数匹配器，其中比较常用的一些有：

• aryEq(X value)：通过Arrays.equals()进行匹配，适用于数组对象；
• isNull()：当输入值为Null时匹配；
• notNull()：当输入值不为Null时匹配；
• same(X value)：当输入值和预期值是同一个对象时匹配；
• lt(X value), leq(X value), geq(X value), gt(X value)：当输入值小于、小等于、大等于、大于预期值时匹配，适用于数值类型；
• startsWith(String prefix), contains(String substring), endsWith(String suffix)：当输入值以预期值开头、包含预期值、以预期值结尾时匹配，适用于String类型；
• matches(String regex)：当输入值与正则表达式匹配时匹配，适用于String类型。

自定义参数匹配器

预定义的参数匹配器可能无法满足一些复杂的情况，这时你需要定义自己的参数匹配器。在上一节中，我们希望能有一个匹配器对 SQL 中关键字的大小写不敏感，使用 anyObject 其实并不是一个好的选择。对此，我们可以定义自己的参数匹配器 SQLEquals。

要定义新的参数匹配器，需要实现 org.easymock.IArgumentMatcher 接口。其中，matches(Object actual) 方法应当实现输入值和预期值的匹配逻辑，而在 appendTo(StringBuffer buffer) 方法中，你可以添加当匹配失败时需要显示的信息。以下是 SQLEquals 实现的部分代码（完整的代码可以在 src.zip 中找到）：

                

            public class SQLEquals implements IArgumentMatcher {

            private String expectedSQL = null;

            public SQLEquals(String expectedSQL) {

            this.expectedSQL = expectedSQL;

            }

            ......

            public boolean matches(Object actualSQL) {

            if (actualSQL == null && expectedSQL == null)

            return true;

            else if (actualSQL instanceof String)

            return expectedSQL.equalsIgnoreCase((String) actualSQL);

            else

            return false;

            }

            }

            

在实现了 IArgumentMatcher 接口之后，我们需要写一个静态方法将它包装一下。这个静态方法的实现需要将 SQLEquals 的一个对象通过 reportMatcher 方法报告给EasyMock：

                

            public static String sqlEquals(String in) {

            reportMatcher(new SQLEquals(in));

            return in;

            }

            

这样，我们自定义的 sqlEquals 匹配器就可以使用了。我们可以将上例中的 executeQuery 方法设定修改如下：

mockStatement.executeQuery(sqlEquals("SELECT * FROM sales_order_table")); expectLastCall().andStubReturn(mockResultSet);

在使用 executeQuery("select * from sales_order_table") 进行方法调用时，该预期行为将被匹配。

回页首

4．特殊的 Mock 对象类型

到目前为止，我们所创建的 Mock 对象都属于 EasyMock 默认的 Mock 对象类型，它对预期方法的调用次序不敏感，对非预期的方法调用抛出 AssertionError。除了这种默认的 Mock 类型以外，EasyMock 还提供了一些特殊的 Mock 类型用于支持不同的需求。

Strick Mock 对象

如果 Mock 对象是通过 EasyMock.createMock() 或是 IMocksControl.createMock() 所创建的，那么在进行 verify 验证时，方法的调用顺序是不进行检查的。如果要创建方法调用的先后次序敏感的 Mock 对象（Strick Mock），应该使用 EasyMock.createStrickMock() 来创建，例如：

ResultSet strickMockResultSet = createStrickMock(ResultSet.class);

类似于 createMock，我们同样可以用 IMocksControl 实例来创建一个 Strick Mock 对象：

IMocksControl control = EasyMock.createStrictControl(); ResultSet strickMockResultSet = control.createMock(ResultSet.class);

Nice Mock 对象

使用 createMock() 创建的 Mock 对象对非预期的方法调用默认的行为是抛出 AssertionError，如果需要一个默认返回0，null 或 false 等"无效值"的 "Nice Mock" 对象，可以通过 EasyMock 类提供的 createNiceMock() 方法创建。类似的，你也可以用 IMocksControl 实例来创建一个 Nice Mock 对象。

回页首

5．EasyMock 的工作原理

EasyMock 是如何为一个特定的接口动态创建 Mock 对象，并记录 Mock 对象预期行为的呢？其实，EasyMock 后台处理的主要原理是利用 java.lang.reflect.Proxy 为指定的接口创建一个动态代理，这个动态代理，就是我们在编码中用到的 Mock 对象。EasyMock 还为这个动态代理提供了一个 InvocationHandler 接口的实现，这个实现类的主要功能就是将动态代理的预期行为记录在某个映射表中和在实际调用时从这个映射表中取出预期输出。下图是 EasyMock 中主要的功能类：

和开发人员联系最紧密的是 EasyMock 类，这个类提供了 createMock、replay、verify 等方法以及所有预定义的参数匹配器。

我们知道 Mock 对象有两种创建方式：一种是通过 EasyMock 类提供的 createMock 方法创建，另一种是通过 EasyMock 类的 createControl 方法得到一个 IMocksControl 实例，再由这个 IMocksControl 实例创建 Mock 对象。其实，无论通过哪种方法获得 Mock 对象，EasyMock 都会生成一个 IMocksControl 的实例，只不过第一种方式中的 IMocksControl 的实例对开发人员不可见而已。这个 IMocksControl 的实例，其实就是 MocksControl 类的一个对象。MocksControl 类提供了 andReturn、andThrow、times、createMock 等方法。

MocksControl 类中包含了两个重要的成员变量，分别是接口 IMocksBehavior 和 IMocksControlState 的实例。其中，IMocksBehavior 的实现类 MocksBehavior 是 EasyMock 的核心类，它保存着一个 ExpectedInvocationAndResult 对象的一个列表，而 ExpectedInvocationAndResult 对象中包含着 Mock 对象方法调用和预期结果的映射。MocksBehavior 类提供了 addExpected 和 addActual 方法用于添加预期行为和实际调用。

MocksControl 类中包含的另一个成员变量是 IMocksControlState 实例。IMocksControlState 拥有两个不同的实现类：RecordState 和 ReplayState。顾名思义，RecordState 是 Mock 对象在 Record 状态时的支持类，它提供了 invoke 方法在 Record 状态下的实现。此外，它还提供了 andReturn、andThrow、times 等方法的实现。ReplayState 是 Mock 对象在 Replay 状态下的支持类，它提供了 invoke 方法在 Replay 状态下的实现。在 ReplayState 中，andReturn、andThrow、times 等方法的实现都是抛出IllegalStateException，因为在 Replay 阶段，开发人员不应该再调用这些方法。

当我们调用 MocksControl 的 createMock 方法时，该方法首先会生成一个 JavaProxyFactory 类的对象。JavaProxyFactory 是接口 IProxyFactory 的实现类，它的主要功能就是通过 java.lang.reflect.Proxy 对指定的接口创建动态代理实例，也就是开发人员在外部看到的 Mock 对象。

在创建动态代理的同时，应当提供 InvocationHandler 的实现类。MockInvocationHandler 实现了这个接口，它的 invoke 方法主要的功能是根据 Mock 对象状态的不同而分别调用 RecordState 的 invoke 实现或是 ReplayState 的 invoke 实现。

创建 Mock 对象

下图是创建 Mock 对象的时序图：

当 EasyMock 类的 createMock 方法被调用时，它首先创建一个 MocksControl 对象，并调用该对象的 createMock 方法创建一个 JavaProxyFactory 对象和一个 MockInvocationHandler 对象。JavaProxyFactory 对象将 MockInvocationHandler 对象作为参数，通过 java.lang.reflect.Proxy 类的 newProxyInstance 静态方法创建一个动态代理。

记录 Mock 对象预期行为

记录 Mock 的预期行为可以分为两个阶段：预期方法的调用和预期输出的设定。在外部程序中获得的 Mock 对象，其实就是由 JavaProxyFactory 创建的指定接口的动态代理，所有外部程序对接口方法的调用，都会指向 InvocationHandler 实现类的 invoke 方法。在 EasyMock 中，这个实现类是 MockInvocationHandler。下图是调用预期方法的时序图：

当 MockInvocationHandler 的 invoke 方法被调用时，它首先通过 reportLastControl 静态方法将 Mock 对象对应的 MocksControl 对象报告给 LastControl 类，LastControl 类将该对象保存在一个 ThreadLocal 变量中。接着，MockInvocationHandler 将创建一个 Invocation 对象，这个对象将保存预期调用的 Mock 对象、方法和预期参数。

在记录 Mock 对象预期行为时，Mock 对象的状态是 Record 状态，因此 RecordState 对象的 invoke 方法将被调用。这个方法首先调用 LastControl 的 pullMatchers 方法获取参数匹配器。如果您还记得自定义参数匹配器的过程，应该能想起参数匹配器被调用时会将实现类的实例报告给 EasyMock，而这个实例最终保存在 LastControl 中。如果没有指定参数匹配器，默认的匹配器将会返回给 RecordState。

根据 Invocation 对象和参数匹配器，RecordState 将创建一个 ExpectedInvocation 对象并保存下来。

在对预期方法进行调用之后，我们可以对该方法的预期输出进行设定。我们以

expectLastCall().andReturn(X value).times(int times)

为例说明。如果 times 方法未被显式的调用，EasyMock 会默认作为 times(1) 处理。下图是设定预期输出的时序图：

在预期方法被调用时，Mock 对象对应的 MocksControl 对象引用已经记录在 LastControl 中，expectLastCall 方法通过调用 LastControl 的 lastControl 方法可以获得这个引用。MocksControl 对象的 andReturn 方法在 Mock 对象 Record 状态下会调用 RecordState 的 andReturn 方法，将设定的预期输出以 Result 对象的形式记录下来，保存在 RecordState 的 lastResult 变量中。

当 MocksControl 的 times 方法被调用时，它会检查 RecordState 的 lastResult 变量是否为空。如果不为空，则将 lastResult 和预期方法被调用时创建的 ExpectedInvocation 对象一起，作为参数传递给 MocksBehavior 的 addExpected 方法。MocksBehavior 的 addExpected 方法将这些信息保存在数据列表中。

在 Replay 状态下调用 Mock 对象方法

EasyMock 类的 replay 方法可以将 Mock 对象切换到 Replay 状态。在 Replay 状态下，Mock 对象将根据之前的设定返回预期输出。下图是 Replay 状态下 Mock 对象方法调用的时序图：

在 Replay 状态下，MockInvocationHandler 会调用 ReplayState 的 invoke 方法。该方法会把 Mock 对象通过 MocksBehavior 的 addActual 方法添加到实际调用列表中，该列表在 verify 方法被调用时将被用到。同时，addActual 方法会根据实际方法调用与预期方法调用进行匹配，返回对应的 Result 对象。调用 Result 对象的 answer 方法就可以获取该方法调用的输出。

回页首

6．使用 EasyMock 进行单元测试小结

如果您需要在单元测试中构建 Mock 对象来模拟协同模块或一些复杂对象，EasyMock 是一个可以选用的优秀框架。EasyMock 提供了简便的方法创建 Mock 对象：通过定义 Mock 对象的预期行为和输出，你可以设定该 Mock 对象在实际测试中被调用方法的返回值、异常抛出和被调用次数。通过创建一个可以替代现有对象的 Mock 对象，EasyMock 使得开发人员在测试时无需编写自定义的 Mock 对象，从而避免了额外的编码工作和因此引入错误的机会。

回页首

下载

	关于下载方法的信息

参考资料

• 如果您想要获得 EasyMock 完整的文档和 API，您可以访问 EasyMock 的主页：http://www.easymock.org/。
  
  
• 您可以在 JUnit 的主页上找到完整的文档和相关下载：http://www.junit.org/index.htm。
  
  
• 通过 Developer Works 上的文章，您可以和其它的框架做比较：利用 Eclipse 进行单元测试。
  
  

• 在Source Forge上，你可以下载到最新的 EasyMock 相关代码：http://sourceforge.net/project/showfiles.php?group_id=82958。
  
  
• Eclipse 的相关下载可以在 http://www.eclipse.org/ 上找到。

时间：2006-05-17 作者：Ajay Vohra, Deepak Vohra 浏览次数： 8856 本文关键字：Apache, Poi, Apache Poi, WebLogic Server, Excel

文章工具  推荐给朋友  打印文章

　　Apache Jakarta POI项目提供了用于访问和生成Excel文档的组件。POI HSSF API用于生成Excel Workbook以及将Excel电子表格添加到workbook。Excel电子表格由行和单元格组成。电子表格的页面布局和字体也使用POI HSSF API进行设置。

　　通常要求将数据库表呈现在Excel电子表格中。同样，开发人员的需求也可以保存到数据库表中的Excel电子表格中。Apache POI HSSF项目旨在提供一个创建Excel电子表格的API。使用POI HSSF项目生成的Excel电子表格中的数据可以是XML文档中的静态数据，或者是从一个数据库中动态检索到的数据。此外，Excel文档也可以被转换为XML文档或者保存在数据库中。在本教程中，我们将讨论在WebLogic Server中从一个MySQL数据库表创建Excel电子表格的步骤，随后将该Excel电子表格保存在一个数据库表中。

初步设置

　　org.apache.poi.hssf.usermodel包提供POI HSSF项目的实现。要生成或解析Excel电子表格，需要在类路径中设置org.apache.poi.hssf.usermodel包类。下载Apache POI库poi-bin-2.5.1-final-20040804.zip文件，将该zip文件解压缩所到一个安装目录(http://jakarta.apache.org/poi/)。安装WebLogic Server 8.1。下载MySQL数据库(www.mysql.com)。解压缩MySQL zip文件mysql-4.0.25-win32.zip到一个目录下。安装MySQL数据库。下载MySQL Connector/J JDBC驱动程序(www.mysql.com/products/connector/j/)。解压缩MySQL zip文件mysql-connector-java-3.1.10.zip到一个目录下。添加MySQL JDBC驱动程序jar文件mysql-connector-java-3.1.10-bin.jar到<weblogic81>\samples\domains\examples\startExamplesServer脚本CLASSPATH变量。

　　使用下面的DOS命令登录到MySQL数据库：

　　>mysql

　　使用下面的命令访问示例数据库测试：

　　mysql>use test

　　在MySQL数据库中创建一个示例数据库表，将在此生成Excel电子表格。清单1展示了创建示例表Catalog的SQL脚本。

　　清单1：Catalog.sql

CREATE TABLE Catalog(CatlogId VARCHAR(25)

PRIMARY KEY, Journal VARCHAR(25), Section VARCHAR(25),

Edition VARCHAR(25),  Title Varchar(125), Author Varchar(25));



INSERT INTO Catalog VALUES('catalog1', 'dev2dev',

'WebLogic Platform 8.1',

'Oct 2004',  'BEA WebLogic Platform 8.1 SP3 Evaluation Guide',

'dev2dev');



INSERT INTO Catalog VALUES('catalog2', 'dev2dev',

'WebLogic Server',

'Feb 2005',  'Application Architecture for Applications Built on

BEA WebLogic Platform 8.1', 'Bob Hensle');



INSERT INTO Catalog VALUES('catalog3', 'dev2dev',

'WebLogic Integration',

'March 2005',  'The BEA WebLogic Platform and Host Integration',

'Tom Bice');

　　接下来，我们将向WebLogic Server Classpath添加Apache POI .jar文件，并在WebLogic Server中创建一个JDBC数据源来检索用于Excel电子表格的数据。

　　添加poi-2.5.1-final-20040804.jar文件到<weblogic81>\samples\domains\examples\startExamplesServer脚本中的CLASSPATH变量中。<weblogic81>是安装WebLogic Server的目录。

　　接下来，使用MySQL数据库在WebLogic Server中创建JDBC连接。使用startExamplesServer脚本启动示例服务器。使用URL http://localhost:7001/console或者WebLogic Server Examples索引中的Administration Console链接来访问管理控制台。在管理控制台中，右击examples>Services>JDBC>Connection Pools节点，并选择Configure a new JDBCConnectionPool。指定以下连接属性来配置JDBC连接池：

• 数据库类型：MySQL
• JDBC驱动程序：MySQL's Driver (Type 4)
• 数据库名称：test
• 主机名：localhost
• 端口号：3306
• 驱动程序类名：com.mysql.jdbc.Driver
• 连接URL：jdbc:mysql://localhost:3306/test

　　接下来，在管理控制台中配置JDBC数据源。右击examples>Services>JDBC>DataSources节点，并选择Configure a new JDBCTxDataSource。在Configure the data source框中指定数据源名和JNDI名——例如，MySqlDS。在Connect to connection pool框中选择先前使用MySQL数据库配置的连接池。在Target the datasource框中选择examplesServer。这样就使用MySQL数据库配置了一个数据源。

使用Apache POI生成Excel文档

　　在这一节中，我们将从示例数据库表生成Excel电子表格。首先，创建一个生成Excel电子表格的JSP应用程序。

　　在JSP中，将从一个MySQL数据库表创建Excel电子表格。使用Apache POI HSSF API来生成Excel电子表格。Apache POI HSSF包中含有用于Excel电子表格的不同组件的类。表1列出了Apache POI HSSF包中一些常用的类：

　　首先，导入Apache POI HSSF包：

  <%@ page import="org.apache.poi.hssf.usermodel.*,  java.sql.*,

java.io.*,javax.naming.InitialContext"%>

  HSSFWorkbook wb=new HSSFWorkbook();

　　接下来，创建一个Excel电子表格：

  HSSFSheet sheet1=wb.createSheet("sheet1");

　　该电子表格的数据是从MySQL数据库表检索得到的。从数据库获得JDBC连接。JDBC连接是使用datasource JNDI MySqlDS获得的。

  InitialContext initialContext = new InitialContext();

javax.sql.DataSource ds = (javax.sql.DataSource)

initialContext.lookup("MySqlDS");

java.sql.Connection conn = ds.getConnection();

　　创建一个java.sql.Statement，并从示例表Catalog获得结果集：

  Statement stmt=conn.createStatement();

ResultSet resultSet=stmt.executeQuery("Select * from Catalog");

　　为Excel电子表格创建一个标题行。Excel电子表格中的行从“0”开始。

  HSSFRow row=sheet1.createRow(0);

　　对应于表的列设置标题行单元格的值。行单元格也是从“0”开始。例如，行中第一个单元格的值被使用setCellValue方法设置为CatalogId。

  row.createCell((short)0).setCellValue("CatalogId");

　　要向电子表格添加行，迭代结果集并为每个表格行添加一行。从ResultSet检索列值，并在行单元格中设置这些值。

for (int i=1;resultSet.next(); i++)

{

row=sheet1.createRow(i);

row.createCell((short)0).setCellValue(resultSet.getString(1));

row.createCell((short)1).setCellValue(resultSet.getString(2));

row.createCell((short)2).setCellValue(resultSet.getString(3));

row.createCell((short)3).setCellValue(resultSet.getString(4));

row.createCell((short)4).setCellValue(resultSet.getString(5));

} 

　　创建一个FileOutputStream来将Excel电子表格输出到XLS文件。每个XLS文件表示一个Excel电子表格：

　　FileOutputStream output=new文件OutputStream(new文件("c:/excel/catalog.xls"));

　　将Excel电子表格输出到XLS文件：

  wb.write(output);

　　在“参考资料”部分有用于生成Excel电子表格的ExcelWebLogic.jsp JSP。

　　要在WebLogic Server中运行ExcelWebLogic.jsp JSP，复制该JSP到<weblogic81>\samples\server\examples\build\mainWebApp目录。使用URL http://localhost:7001/ExcelWebLogic.jsp运行该JSP。

　　生成的Excel电子表格可以在Excel (http://office.microsoft.com/en-us/FX010858001033.aspx)或Excel Viewer工具tool (http://office.microsoft.com/en-us/assistance/HA011620741033.aspx)中打开。

将Excel文档保存在数据库表中

　　本节我们将使用Apache POI API将一个Excel电子表格保存在MySQL数据库表中。要保存的示例Excel文档是catalog.xls，即，前一节所生成的电子表格。该Excel电子表格被保存在MySQL表Catalog中。使用MySQL命令删除前一节中用于生成Excel文档的Catalog表：

  MySQL>DROP table Catalog;

　　开发一个JSP应用程序来将示例Excel文档保存在MySQL数据库中。在JSP应用程序中导入Apache POI包org.apache.poi.poifs.filesystem和org.apache.poi.hssf.usermodel。org.apache.poi.poifs.filesystem包中包含创建Excel workbook的类，而org.apache.poi.hssf.usermodel包中包含表示Excel workbook、电子表格、电子表格行和行单元格的类。

  <%@ page import="org.apache.poi.poifs.filesystem.*,

org.apache.poi.hssf.usermodel.*, java.sql.*,

java.io.*,javax.naming.InitialContext"%>

　　像前一节一样，从MySQL datasource获得JDBC连接：

  InitialContext initialContext = new InitialContext();

javax.sql.DataSource ds =  (javax.sql.DataSource)

initialContext.lookup("MySqlDS");

java.sql.Connection conn = ds.getConnection();

　　从JDBC连接创建java.sql.Statement：

  Statement stmt=conn.createStatement();

　　创建一个MySQL表来保存Excel电子表格：

  String createTable="CREATE TABLE Catalog(CatalogId  VARCHAR(25) PRIMARY KEY,Journal

VARCHAR(25),Section VARCHAR(25),Edition VARCHAR(25),Title Varchar(125),Author  Varchar(25))";

  stmt.execute(createTable);

　　创建一个POIFSFileSystem来读取Excel文档：

  File catalogExcel=new File("C:/ExcelWebLogic/catalog.xls");

FileInputStream inputStream=new FileInputStream(catalogExcel);

POIFSFileSystem fileSystem=new POIFSFileSystem(inputStream);

　　从POIFSFileSystem获得一个HSSF workbook：

  HSSFWorkbook wb=new HSSFWorkbook(fileSystem);

　　从Excel workbook获得一个Excel电子表格：

  HSSFSheet sheet1=wb.getSheet("sheet1");

　　使用row iterator迭代电子表格中的行：

  java.util.Iterator rowIterator=sheet1.rowIterator();

HSSFRow row=(HSSFRow)rowIterator.next();

　　对于每一行，迭代行单元格的值。例如，CatalogId行单元格值是使用以下代码检索的：

  String catalogId=row.getCell((short)0).getStringCellValue();

　　对于Excel电子表格中的每一行，添加一个表格行：

String exceltable="INSERT INTO Catalog VALUES("+"\'"+catalogId+"\

'"+","+"\'"+journal

+"\'"+","+"\'"+section+"\'"+","+"\'"+edition+"\'"+","+"\'"+title+"\

'"+","+"\'"+author+"\'"+")";

stmt.execute(exceltable); 

　　复制POIWebLogic.jsp到<weblogic81>\samples\server\examples\build\mainWebApp目录。使用URL http://localhost:7001/POIWebLogic.jsp运行JSP。这样就从Excel电子表格生成一个MySQL数据库表。在“参考资料”部分有用于从Excel电子表格生成数据库表的POIWebLogic.jsp。

结束语

　　在本教程中，我们从一个MySQL数据库表生成了一个Excel电子表格，随后将该电子表格保存在一个数据库表中。WebLogic Server提供了一个数据源以及运行JSP应用程序的J2EE应用服务器，从而方便了从数据库表到Excel电子表格以及从电子表格到数据库表的转换。

原文出处:http://wldj.sys-con.com/read/185302.htm

时间：2007-08-16 作者：Hetal C. Shah 浏览次数： 1202 本文关键字：XMLBeans, xml, xml schema, xsd, schema,  apache, 模式,  xml-java绑定,  java绑定,  数据绑定

文章工具  推荐给朋友  打印文章

　　XMLBeans提供了底层XML数据的对象视图，同时还能访问原始的XML信息集合。通过递增的解除封送xml数据和高效的访问XML 模式内置数据类型的方法，XMLBeans交付了较好的性能。下面两种特性几乎百分之百的支持XML模式，并在操作数据期间定时验证XML数据 ，从而使XMLBeans非常适用于XML-Java 数据绑定。

　　XMLBeans目前处于 Apache 项目的孵化过程中，并且证明对于Java开发人员进行XML-Java数据绑定是非常有用的。

　　本文后面的资源部分提供了本文示例代码和其他文件的下载。所有示例代码均在Apache XMLBeans 1.02、Java 1.4.2_02和Microsoft Windows 2000的环境下进行了测试。

创建一个XMLBean

　　在开始创建XMLBeans之前，需要下载并在系统中安装Apache XMLBeans 1.02。当从XMLBeans 的归档文件中提取出文件之后，将会在解压文件中看到bin目录和lib目录。随后，把bin目录放到路径中，把lib目录中的xbean.jar包放到classpath路径中。

　　XML 模式文件(XSD文件)创建了XMLBeans类。这些XMLBeans类能够解析所有符合XML模式的XML 实例文档。同样，通过使用这些XMLBeans类，也能够创建出实例文档。

　　例如，下面的weather_latlong.xsd模式列表描述了xml文档的内容,该文档包含了某个地理位置的天气、经纬度信息，这些信息全部基于zip代码。

<xsd:schema

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<!-- This XML Schema describes xml documents

containing either weather details or latlong

details of a location based on Zipcode Two Global

elements Weather and Latlong, and one Global

Attribute Zipcode are declared.-->

<xsd:element name="Weather">

  <xsd:complexType>

   <xsd:sequence>

    <xsd:element name="Temperature"

         type="xsd:float"/>

    <xsd:element name="Humidity"

         type="xsd:float"/>

    <xsd:element name="Visibility"

         type="xsd:float"/>

    <xsd:element name="Datetime"

         type="xsd:dateTime"/>

   </xsd:sequence>

  <xsd:attribute ref="Zipcode"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Latlong">

  <xsd:complexType>

   <xsd:sequence>

    <xsd:element name="Latitude"

         type="xsd:string"/>

    <xsd:element name="Longitude"

         type="xsd:string"/>

    </xsd:sequence>

   <xsd:attribute ref="Zipcode"/>

  </xsd:complexType>

</xsd:element>

<xsd:attribute name="Zipcode"

         type="xsd:string"/>

</xsd:schema>

　　接下来的步骤将生成一组XMLBeans类，它们表示上面的XSD类型模式。在工作目录（从示例归档文件提取文件的位置）的提示符中，输入以下命令行：

scomp -out weather.jar weather_latlong.xsd

　　在编译完以上的模式后，XMLBeans生成如下五个接口。WeatherDocument、WeatherDocument$Weather、LatlongDocument、LatlongDocument$Latlong和ZipcodeAttribute。

　　在此，WeatherDocument接口表示文档元素，WeatherDocument$Weather接口表示全局元素Weather。类似地，LatlongDocument和LatlongDocument$Latlong接口表示全局元素Latlong。ZipcodeAttribute接口代表了全局属性Zipcode。

XMLBeans类

　　下面将详细讨论XMLBeans类。 XMLBeans提供了46种java类型，反映了XML 模式规范中定义的46种内置类型。例如，W3C定义了一个xsd:string类型，XMLBeans就提供了一个XmlString数据类型与之对应。

　　在weather_latlong.xsd 模式创建的Weather接口为xsd:float类型的局部元素Visibility声明了如下的两种方法：

float getVisibility();

　　和

org.apache.xmlbeans.XmlFloat xgetVisibility();

　　对于46种java类型中的任何一种，XMLBeans 都提供了两种访问数据的方法。在此，一种方法为xsd:float返回了XmlFloat类型，而另一种方法为xsd:float返回了一个普通的java类型如float类型。

　　Xget形式的函数在性能上要优于get形式的函数，因为get形式的函数必须要把数据转化成为最合适的java类型。

　　当模式被编译后，模式类型的名称将会变得符合java的命名规则。换句话说，stock-quote这样的名称将变为StockQuote。另外，模式名称空间的URIs变成了模式生成的XMLBeans类型的包名。如果包含的模式没有声明目标名称空间，那么所有的java类都将放在noNamespace这个包中。当出现了类命名冲突时，生成的类名字后面将加上相应的数字——例如, timeStamp3。

　　对于全局元素和属性，XMLBeans 模式编译器将分别生成名称以Document和Attribute结尾的接口。

　　对于在另一个元素或类型的声明中局部声明的命名类型，XMLBeans会在元素或类型接口中生成一个内部接口，形成嵌套结构。

　　考虑下面的employee.xsd 模式列表。

<?xml version="1.0" encoding="UTF-8"?>

<!-- This XML Schema describes Employee's

    Jobstatus -->

<xsd:schema

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:complexType name="Employee">

  <xsd:sequence>

   <xsd:element name="Jobstatus">

    <xsd:simpleType>

     <xsd:restriction base="xsd:NMTOKEN">

      <xsd:enumeration value="fullTime"/>

      <xsd:enumeration value="hourly"/>

     </xsd:restriction>

    </xsd:simpleType>

   </xsd:element>

  </xsd:sequence>

</xsd:complexType>

</xsd:schema>

　　因此，XMLBeans在元素Employee的接口中生成了一个内部接口Jobstatus，嵌套在了Employee接口中。

public interface Employee

  extends org.apache.xmlbeans.XmlObject

{

...

public interface Jobstatus

   extends org.apache.xmlbeans.XmlNMTOKEN

  {

  }

}

　　Employee类在这里扩展了org.apache.xmlbeans.XmlObject，这是所有XMLBeans类型的基础接口。所有的内置模式类型，用户定义类型和派生的模式类型都从XmlObject中继承而来。

使用XMLBeans类解除封送XML文件

　　下面的一小段weather_unmarshal.java代码阐明了怎样使用XMLBeans类从weatherInput.xml.文件的XML文档中获取天气信息。

String filePath = "weatherInput.xml";

java.io.File inputXMLFile =

new java.io.File(filePath);

// Parse XML Document.

WeatherDocument weatherDoc =

WeatherDocument.Factory.parse(inputXMLFile);

// Get object reference of root element Weather.

WeatherDocument.Weather weatherElement =

weatherDoc.getWeather();

　　通过调用WeatherDocument.Factory.parse(File)方法来解析XML文件，该方法返回一个WeatherDocument对象。随后对weatherDocument对象调用getWeather()方法来获取根元素Weather的对象引用。

　　要获得Weather元素的内容，简单调用weatherElement的相应的get方法，它将直接映射模式定义的元素和属性名称：

// Call the appropriate 'get' methods of

// weatherElement that

// directly map to the element and attribute names

// defined in the schema.

Calendar timeStamp = weatherElement.getDatetime();

System.out.println("Weather details of zipcode "

+ weatherElement.getZipcode() + " at "

+ timeStamp);

System.out.println("Temperature is "

+ weatherElement.getTemperature());

System.out.println("Humidity is "

+ weatherElement.getHumidity());

System.out.println("Visibility is "

+ weatherElement.getVisibility());

　　输出的结果是：

Weather details of zipcode 92834-2345 at 2003-11-13T05:29:27-03:01

Temperature is 85.3

Humidity is 50.0

Visibility is 5.5

模式声明多个全局元素时如何解除封送

　　在上面的例子中，我们假设输入XML文档始终包含天气信息。然而，在实际中，由于weather_latlong.xsd文件通过声明两个全局元素（Weather和Latlong）同时描述了二者的详细信息，因此输入XML文档中可能包含天气信息也可能包含经纬度信息。。

　　有两种方法可以解析一个xml文档并将其绑定到相应XMLBeans类型的实例。在上述的例子中，我们用WeatherDocument.Factory.parse()方法解析XML文档。另外一种方式是使用XMLBeans内置的XmlObject类。

　　下面的一小段weather_unmarshal_xmlObject.java代码阐述了怎样使用XmlObject类获取xml实例文档中包含的天气和经纬度信息。

public static void main(String args[]) {

try {

if (args.length < 1 ) {

System.out.println("Usage : java "

+"weather_unmarshal_xmlObject <<InputFilePath>>");

return;

}

String filePath = args[0];

java.io.File inputXMLFile

   = new java.io.File(filePath);

XmlObject xmlObjExpected =

XmlObject.Factory.parse(inputXMLFile);

// Check document type of the object returned by

// the call to XmlObject.Factory.parse() method.

// If type of object returned is of

//noNamespace.WeatherDocument, then input xml

//document carries weather details of a location.

if (xmlObjExpected instanceof

noNamespace.WeatherDocument) {

  WeatherDocument weatherDoc =

    (noNamespace.WeatherDocument)xmlObjExpected;

  WeatherDocument.Weather weatherElement =

        weatherDoc.getWeather();

  Calendar timeStamp =

    weatherElement.getDatetime();

  System.out.println

    ("Weather details of zipcode "

    + weatherElement.getZipcode() + " at "

    + timeStamp  + " : \n\n");

  System.out.println("Temperature is "

        + weatherElement.getTemperature());

  System.out.println("Humidity is "

        + weatherElement.getHumidity());

  System.out.println("Visibility is "

        + weatherElement.getVisibility());

// else if type of object returned is of

// noNamespace.LatlongDocument, then input xml

//document carries latlong details of a location.

} else if(xmlObjExpected instanceof

    noNamespace.LatlongDocument) {

        LatlongDocument latLongDoc =

        (noNamespace.LatlongDocument)xmlObjExpected;

        LatlongDocument.Latlong latLongElement =

        latLongDoc.getLatlong();

    System.out.println

   ("Latlong details of zipcode "

      + latLongElement.getZipcode() + " : \n\n");

    System.out.println("Latitude is "

      + latLongElement.getLatitude());

    System.out.println("Longitude is "

      + latLongElement.getLongitude());

// else input xml document is well formed , but

// doesn't conform to weather_latlong.xsd schema

// file.

} else {

        System.out.println("Input xml document "

          + "doesn't conform to weather_latlong.xsd");

}

} catch (Exception e) {

    e.printStackTrace();

  }

}

}

　　为了获得输入XML文档的内容,我们先检查XmlObject.Factory.parse()返回的对象的文档类型，然后把返回的对象转化为相应的文档类型，以供稍后处理。另一段有趣的代码是最后的else代码块，它将处理格式良好的XML文档不符合weather_latlong.xsd模式的情况。

创建一个新的XML文档

　　下面的一小段latlong_marshal.java代码阐述了如何使用XMLBeans生成的类创建一个包含经纬度信息的新xml实例文档。

LatlongDocument latLongDoc;

LatlongDocument.Latlong latLongElement;

XmlOptions xmlOptions;

// LatlongDocument.Factory.newInstance() creates

// and returns a LatlongDocument object.

latLongDoc= LatlongDocument.Factory.newInstance();

// addNewLatlong() method is called on the

// document object to create and add a new

// LatLong Element to document.

latLongElement = latLongDoc.addNewLatlong();

　　LatlongDocument.Factory.newInstance()创建了一个LatlongDocument对象并且返回该对象。随后对文档对象调用addNewLatlong()方法创建并向文档增加一个新的LatLong元素。

　　要向LatLong元素添加数据， 简单调用latLongElement的相应的Set方法即可，它将直接映射模式中定义的的元素和属性名称。

latLongElement.setZipcode("91023");

latLongElement.setLatitude("33.8792");

latLongElement.setLongitude("117.8974");

　　最后的代码段将LatLong元素的当前状态写到了标准的输出流中。

xmlOptions = new XmlOptions();

 

// Requests use of whitespace for easier reading

xmlOptions.setSavePrettyPrint();

 

// Requests that nested levels of the xml

// document to be indented by multiple of 4

// whitespace characters

xmlOptions.setSavePrettyPrintIndent(4);

 

String xmlStr = latLongDoc.xmlText(xmlOptions);

 

// Writes the current state of the LatLong

// element to a standard output stream

 

System.out.println("XML Instance Document is : "

  + "\n\n\n " + xmlStr );

　　xmlText方法用可选的xmlOptions对象控制它的行为。setSavePrettyPrint()方法要求使用空白符，以便方便阅读，而setSavePrettyPrintIndent(4)方法要求在嵌套的XML文档中首行缩进四的倍数个空白符。

　　输出的结果是：

XML Instance Document is :

 

<Latlong Zipcode="91023">

    <Latitude>33.8792</Latitude>

    <Longitude>117.8974</Longitude>

</Latlong>

性能优势

　　与DOM的不同之处是，XMLBeans没有采用解除封送整个xml文档和为每个xml文档结点提供一个对象的方法。使用XMLBeans，只在需要时进行封送和解除封送，因此对于你从来没有查看过的代码，它们是不会被封送和解除封送的。这提高了XMLBeans解决方案的性能。

　　XMLBeans也提供高效的xget版本的函数访问XML模式内置数据类型。

验证

　　分配给内置XMLBeans java类型的值将按照其表示的模式类型的规则进行验证。例如，如果将一个符合条件的名称分配给一个XmlQName数据类型时，如果该名称的前缀不能解析为任何URI，将会抛出XmlValueOutOfRange异常。

　　当xml文档第一次被解析时，将根据模式定义验证其中包含的数据。更有意思的是，无论何时通过XMLBeans生成的java类处理xml文档时，XMLBeans系统将确保遵守模式约束条件。

其他特性

　　XMLBeans对象是可序列化的，因而，可以通过RMI边界传送，也能够很容易的从XML 字符流和字节流中提取，并保存回去。XMLBeans也具有配置功能，因而可以将XML名称映射到Java名称。这样将避免在XML的名称发生变化时重新编写Java代码。由于篇幅限制我们在此不做过多讨论。

结束语

　　XMLBeans 提出了底层XML数据的对象视图，同时还能访问原始的XML信息集合。通过递增的解除封送xml数据和高效的访问XML模式内置数据类型的方法，XMLBeans交付了较好的性能。下面两种特性几乎百分之百的支持XML 模式，并在操作数据期间定时验证XML数据，从而使XMLBeans非常适用于XML-Java 数据绑定。现在web services、BPEL、BPML、基于规则的XML数据转换引擎等实现，都用到了该数据绑定技术。

资源

• 本文的 示例代码包含了模式、Java代码和XML文件。
• XMLeans主页

Digester框架属于Jakarta Commons，它以规则和模式为基础处理XML文档。与SAX和DOM之类的标准API相比，Digester不涉及太多的细节问题，非常适合于对XML文档进行简单的处理。

在Java和XML开发中，一个常见的任务是把XML文档转换成对应的Java Bean对象的层次结构。人们经常用标准的SAX和DOM API来完成这个任务。虽然这两种API都很强大和灵活，但对于某些简单的任务来说，它们显得操作层次太低，也就是说，涉及了太多的细节问题。Jakarta Digester框架能够很好地满足这类场合的需要。

Jakarta的Digester框架从Struts框架发展而来，原先被用来处理struts-config.xml配置文件，但很快人们认识到它有着更广泛的用途，把它转入了Jakarta Commons项目。Jakarta Commons的目标是提供一个“可重用Java组件的仓库”。Digester最新的版本是1.3，于2002年8月13日发布。

Digester框架允许开发者指定一组动作，当解析器在XML文档中发现某些特定的简单模式时动作被执行。Digester框架带有10个预定义的规则（Rule），涵盖了unmarshalling XML（例如创建Bean或设置Bean属性）的大多数需求（ marshalling的原意是指“配制整齐，编组列车”，marshalling是在内存中为Java对象生成XML描述文档的过程，而unmarshalling是指把XML形式的描述转换到可用Java代码操作的对象的过程，我们称之为“反配制”），但必要时用户可以定义和实现自己的规则。

在本文的例子中，我们将反配制下面这个XML文档：

<?xml version="1.0"?> <catalog library="somewhere"> <book> <author>Author 1</author> <title>Title 1</title> </book> <book> <author>Author 2</author> <title>His One Book</title> </book> <magazine> <name>Mag Title 1</name> <article page="5"> <headline>Some Headline</headline> </article> <article page="9"> <headline>Another Headline</headline> </article> </magazine> <book> <author>Author 2</author> <title>His Other Book</title> </book> <magazine> <name>Mag Title 2</name> <article page="17"> <headline>Second Headline</headline> </article> </magazine> </catalog>

下面是Bean的代码。注意使用Digester框架时，Bean类必须定义成public。

import java.util.Vector; public class Catalog { private Vector books; private Vector magazines; public Catalog() { books = new Vector(); magazines = new Vector(); } public void addBook( Book rhs ) { books.addElement( rhs ); } public void addMagazine( Magazine rhs ) { magazines.addElement( rhs ); } public String toString() { String newline = System.getProperty( "line.separator" ); StringBuffer buf = new StringBuffer(); buf.append( "--- Books ---" ).append( newline ); for( int i=0; i<books.size(); i++ ){ buf.append( books.elementAt(i) ).append( newline ); } buf.append( "--- Magazines ---" ).append( newline ); for( int i=0; i<magazines.size(); i++ ){ buf.append( magazines.elementAt(i) ).append( newline ); } return buf.toString(); } } //=================================================== public class Book { private String author; private String title; public Book() {} public void setAuthor( String rhs ) { author = rhs; } public void setTitle( String rhs ) { title = rhs; } public String toString() { return "Book: Author='" + author + "' Title='" + title + "'"; } } //=================================================== import java.util.Vector; public class Magazine { private String name; private Vector articles; public Magazine() { articles = new Vector(); } public void setName( String rhs ) { name = rhs; } public void addArticle( Article a ) { articles.addElement( a ); } public String toString() { StringBuffer buf = new StringBuffer( "Magazine: Name='" + name + "' "); for( int i=0; i<articles.size(); i++ ){ buf.append( articles.elementAt(i).toString() ); } return buf.toString(); } } //=================================================== public class Article { private String headline; private String page; public Article() {} public void setHeadline( String rhs ) { headline = rhs; } public void setPage( String rhs ) { page = rhs; } public String toString() { return "Article: Headline='" + headline + "' on page='" + page + "' "; } }

一、SiteMesh项目简介
      OS(OpenSymphony)的SiteMesh是一个用来在JSP中实现页面布局和装饰（layout and decoration）
的框架组件，能够帮助网站开发人员较容易实现页面中动态内容和静态装饰外观的分离。

      Sitemesh是由一个基于Web页面布局、装饰以及与现存Web应用整合的框架。它能帮助我们在由大
量页面构成的项目中创建一致的页面布局和外观，如一致的导航条，一致的banner，一致的版权，等等。
它不仅仅能处理动态的内容，如jsp，php，asp等产生的内容，它也能处理静态的内容，如htm的内容，
使得它的内容也符合你的页面结构的要求。甚至于它能将HTML文件象include那样将该文件作为一个面板
的形式嵌入到别的文件中去。所有的这些，都是GOF的Decorator模式的最生动的实现。尽管它是由java语言来实现的，但它能与其他Web应用很好地集成。

      官方：http://www.opensymphony.com/sitemesh/

      下载地址：http://www.opensymphony.com/sitemesh/download.action 目前的最新版本是Version 2.3；

二、为什么要使用SiteMesh?

    我们的团队开发J2EE应用的时候，经常会碰到一个比较头疼的问题：

         由于Web页面是由不同的人所开发，所以开发出来的界面通常是千奇百怪，通常让项目管理人员苦笑不得。

     而实际上，任何一个项目都会要求界面的统一风格和美观，既然风格统一，那就说明UI层肯定有很多可以抽出来
共用的静态或动态部分；如何整合这些通用的静态或动态UI呢？Apache Tiles框架站了出来很好的解决了这一问题，
再加上他与struts的完美集成，导致大小项目都把他作为UI层的首选框架，

但是：

   Tiles确实有着它很多的不足之处,下文我会介绍,本文想说的是，除了Apache Tiles框架,其实我们还有更好的解
决方案，那就是:SiteMesh；

本文
  
   介绍了一个基于Web页面的布局、装饰以及应用整合的框架Sitemesh，它能帮助你为你的应用创建一致的外观，
很好的取代Apache Tiles;

三、SiteMesh VS Apache Tiles

     用过struts的朋友应该对Apache Tiles的不会陌生，我曾经有一篇文章介绍过struts中tiles框架的组合与继承，
现在怎么看怎么觉得复杂;
     
      从使用角度来看，Tiles似乎是Sitemesh标签<page:applyDecorator>的一个翻版。其实sitemesh最强的
一个特性是sitemesh将decorator模式用在过滤器上。任何需要被装饰的页面都不知道它要被谁装饰，所以它就
可以用来装璜来自php、asp、CGI等产生的页面了。你可以定义若干个装饰器，根据参数动态地选择装饰器，
产生动态的外观以满足你的需求。它也有一套功能强大的属性体系，它能帮助你构建功能强大而灵活的装饰器。
相比较而言，在这方面Tiles就逊色许多。

      个人觉得在团队开发里面，Apache Tiles框架会导致所有人不仅仅要了解并且清楚Apache Tiles的存在，
并且要特别熟悉每一个Tiles layout模板的作用，否则就可能出现用错模板的情况；除此之外，每个人涉及到
的所有WEB页面都需要去配置文件里面逐个配置，不仅麻烦出错的几率还高；
      而以上所有的不足都是SiteMesh所不存在的；

http://www.iocblog.net/static/2007/569.html

注：sitemesh，一个不错的tiles替代方案，比tiles做的更漂亮优雅。本文是sitemesh官方推荐的入门文档，本来想自己翻译的，突然发现有人先行一步了，就转过来看吧。

以前我通常使用旧式的方法来建立自己的web应用：手工排版，仔细使用每一个字节使其工作在Unicode下，同时使用make文件来适应不同的CPU……

或许现在我们可以换一种方式。

尽管我从没有感觉到需要使用assembly (CISC or RISC)来建立web应用，但也会偶尔觉得我的开发伙伴的工作相当繁琐。特别是我发现很多的开发者在痛苦的寻求一种比较好的方式来控制web应用的基本模块：例如那些页头、页尾、导航栏、打印页面、手持设备的轻量级页面，以及其他更多的问题。到了最后，令人惊异的是大部分人都采用了落后的 includes和复制粘贴方式。

根据经验，我可以采用在 java.net 上开源的servlet 过滤器 SiteMeshn 来简单明了并优雅的解决这些问题。作为一种替代新的templating语言（XSLT）或部署您的页面到新的系统的解决方法，应用SiteMesh可以相当容易处理你的页面，这一切只需要普通的HTML，JSP，servlet(包括Struts)，以及其他常用的技术。

工作原理

SiteMesh 利用了一种很少人知道的servlet规范实现了一种页面过滤器。设想一下，现在有一个简单的jsp页面用来返回当前的日期和时间。通常这个页面请求来到应用服务器，页面被处理，最后处理结果返回到web浏览器。SiteMesh作为一个页面过滤器，在页面被处理之后，返回web浏览器之前，对页面做了一些附加的操作。这个变化简单描述为图一和图二所示的附加步骤。

图一：普通页面处理情况

图二：SiteMesh对页面处理情况

现在看一个简单的例子。

<html>

<head>

<title>Simple Document</title>

</head>

<body>

Hello World! <br />

<%= 1+1 %>

</body>

</html>

你会发现这个页面有一个title和body（类似普通的HTML页面）。你也会发现一小段JSP代码——它将会如同你期望的那样被处理。同时你可以使用任何你想使用的JSP语法和特性来替换这一小段代码。

现在来看一个简单的SiteMesh "装饰（decorator）"页面。列表2显示了一个被SiteMesh调用的JSP页面。

<%@ taglib uri="sitemesh-decorator"

prefix="decorator" %>

<html>

<head>

<title>

My Site - <decorator:title default="Welcome!" />

</title>

<decorator:head />

</head>

<body>

<h1><decorator:title default="Welcome!" /></h1>

<p><decorator:body /></p> 

<p><small>

(<a 

href="?printable=true">printable version</a>

</small></p>

</body>

</html>

查看这个装饰器（decorator），我们能看到一些有趣的东西。首先，在第一行申明了一个SiteMesh标签库。这个标签库包含了与原始页面一起工作时所需的所有东西。你能看到我们使用了两个SiteMesh的装饰标签（declared tags）， <decorator:title> 和 <decorator:body> 。不要惊讶于标签<decorator:title>在原始页面中显示<title>标签中的内容， <decorator:body> 中的内容也是如此。我们在这个页面的HEAD和BODY元素都使用了同一个title标签。（We're making a few fairly radical changes to the page, including repeating the title both in the HEAD element as well as the BODY. ）同时，我们还增加了一个到可打印版本页面的链接。

作为对照，图三显示了原始处理页面，图四显示了被修饰过的处理页面。留意被装饰页面在浏览器窗口显示的标题文字和HTML内容。同时也可以看到增加了一个可打印页面的链接——这个我们回头再说。

图三：原始未修饰页面

图四：被修饰页面

很明显，对比起使用include（例如<jsp:include page="foo.jsp" flush="true" />）来说，以这样的方式使用页头、页尾系统结构要清晰得多。这种方式更易移植、更易理解，同时也鼓励了JSP页面不再使用导航或其他类似的表现层代码。我发现在JSP页面中使用装饰器和CSS的组合比标准HTML的标签更容易去除格式信息。

安装SiteMesh

注意下面的屏幕截图是基于Windows XP Professional， Tomcat 5.0.19，和Java 2 SDK 1.4.2_03的环境之上的。在这里我假定你的Tomcat已经安装完毕并且可以正常工作了。你或许会有一些混淆，但我们已经成功地在Tomcat 4.1 和 WebLogic 测试过，同时 SiteMesh 也支持大部分的web应用服务器。

本文描述的SiteMesh 2.0.1可以在 下载到。 在java.net 上SiteMesh's 的项目库中有四个文件可以下载。sitemesh-2.0.1.jar 是其核心 JAR 文件， sitemesh-2.0.1-sources.zip 的作用正如同其名字所述， sitemesh-example.war 则提供了一个复杂的例子用来显示一些SiteMesh的高级特性。

为了使描述更加简单，我们从sitemesh-blank.war 文件开始。将该WAR文件放入Tomcat 的webapps 目录，WAR包将自动解压显示内容（SoSo注：这里的前提是你的tomcat已经开始工作），如图五所示。

图五： SiteMesh_blank.WAR解开后的内容

我们花点时间描述一下这些文件的作用。

web.xml

首先，WEB-INF/web.xml 文件显示如列表3，这些语句用来安装SiteMesh 过滤器和标签库。如果你决定在一个已有的Web应用中使用SiteMesh，你必须把这些语句添加到你的WEB-INF/web.xml 文件中。

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" 

"http://java.sun.com/dtd/web-app_2_3.dtd"> 

<web-app> 

<!-- Start of SiteMesh stuff --> 

<filter>

<filter-name>sitemesh</filter-name>

<filter-class>com.opensymphony.module.sitemesh.filter.PageFilter</filter-class>

</filter> 

<filter-mapping>

<filter-name>sitemesh</filter-name>

<url-pattern>*.jsp</url-pattern>

</filter-mapping> 

<taglib>

<taglib-uri>sitemesh-page</taglib-uri>

<taglib-location>/WEB-INF/sitemesh-page.tld</taglib-location>

</taglib> 

<taglib>

<taglib-uri>sitemesh-decorator</taglib-uri>

<taglib-location>/WEB-INF/sitemesh-decorator.tld</taglib-location>

</taglib> 

<!-- End of SiteMesh stuff --> 

</web-app>

注意：这里需要注意一下url-pattern的写法-- 如果使用的是Tomcat 5（而不是 Tomcat 4 ），需要将默认的*修改如*.jsp的形式。最新的servlet规范不再支持*样式。

decorators.xml

WEB-INF/decorators.xml 文件用来将一个装饰器名字同一个专门的JSP装饰文件绑定。作为一个例子，这里将JSP装饰文件minimal.jsp同一个称为handheld的装饰器绑定起来。

<decorators defaultdir="/decorators">

<decorator name="main" page="main.jsp">

<pattern>*</pattern>

</decorator>



<decorator name="panel" page="panel.jsp"/>

<decorator name="printable" page="printable.jsp"/>

</decorators>

正如我们在代码列表里看到的一样，我们定义了三个装饰器，他们分别绑定了三个类似的JSP页面。我们可以看到一个默认装饰器（main.jsp），它将被默认运用于所有文件。

缺省的，SiteMesh使用下面的逻辑来选择使用哪一个装饰器：

1. 页面是否使用meta装饰器标签（meta decorator tag）特别指定了一个装饰器？
2. 页面是否是一个框架集（是的话则不应用装饰器）？
3. 页面是否使用了printable=true 参数（是的话则使用打印装饰器）
4. 页面时候使用装饰器文件名特别指定了一个装饰器？
5. 页面是否匹配 decorators.xml 文件里描述的样式？

通常第一条规则仅用来确定该装饰器是否被使用（Conceptually, the first rule that evaluates to true determines the decorator that is used. ）在上面的例子中，当出现printable=true 参数的时候，装饰器printable.jsp （规则 #3）替代了 main.jsp （规则 #5）。在SiteMesh中，这些规则被描述为 mappers。

decorators/*.jsp

这三个decorators目录下的文件是decorators.xml文件中描述的不同装饰器JSP文件。上面是一个简单的装饰器例子，在后面我们将讨论更复杂的示例。

sitemesh-2.0.1.jar

这是SiteMesh最主要的二进制文件，通常被安装在 WEB-INF/lib 目录下。可以在www.opensymphony.com/sitemesh/api 找到这个库的javadoc。

*.tld

SiteMesh使用两个标签库，但大多数人都只需要sitemesh-decorator.tld。你可以在 www.opensymphony.com/sitemesh/tags.html 找到相应的文档。我们已经讲述了最主要的标签：head，title和body。在下一章我们来讨论剩下的标签：getProperty。

SiteMesh高级特性

SiteMesh的一个重要特性是使用原始HTML的meta标签（例如<meta name="foo" content="bar">）从基础页面传递信息到装饰器。作为一个例子，下面我们使用一个meta标签来定义HTML页面的作者。

<html>

<meta name="author" content="test@example.com">

<head>

<title>Simple Document</title>

</head>

<body>

Hello World! <br />

<%= 1+1 %>

</body>

</html>

我们定义一个“smart”装饰器来研究meta标签，如果出现这个标签，则可以得到一个相应的HTML：

<%@ taglib uri="sitemesh-decorator" prefix="decorator" %>

<decorator:usePage id="myPage" />

<html>

<head>

<title>My Site -

<decorator:title default="Welcome!" />

</title>

<decorator:head />

</head>



<body>

<h1><decorator:title default="Welcome!" /></h1>

<h3>

<a href="mailto:<decorator:getProperty property="meta.author" 

default="staff@example.com" />">

<decorator:getProperty property="meta.author"

default="staff@example.com" />

</a></h3><hr />

<decorator:body />

<p><small>

(<a href="?printable=true">printable version</a>

</small>

</p>

</body>

</html>

可以看到我们使用了getProperty标签的一个默认属性——如果没有指定author，我们就设定其为staff。如果你决定使用这个模型储存页面的meta数据，你或许需要和你的开发伙伴一起来确定将使用什么标签以及如何使用他们。简单的，你或许想要使用meta标签来描述诸如页面作者及时间戳之类的东西。更复杂一些，你或许会想像XML文件一样标准化的管理你的站点导航，同时使用meta标签来通过页面节点转到装饰器。（At the complex end, you may do things like standardize on an XML file to manage your site navigation and use a meta tag to pass the page's node to the decorator. ）

图六显示了应用上面的装饰器JSP页面之后生成的结果。

图六：meta标签显示

这些页面属性非常强大，并且拥有着很多不同的特性，并不仅止于meta标签（ 常用页面特性列表）。使用SiteMesh一段时间之后，你就会开始思考HTML和JSP作为一种简单标记语言的机制——接近最原始的HTML——无需操作就可以完整的切换到XML/XSL 或其他模版引擎。

小结

综上所述，SiteMesh 提供了一个强大、易用、易结合的机制来使用页面模版。可以想象，它将会有很广泛的用户群。例如，你可以定义一个装饰器针对不同的浏览器输出额外的页面调试信息（和特定web浏览器结合之后将产生一个特别的功能，你可以强制指定使用某一种用户代理）。你也可以定义一个装饰器产生stripped-down XML输出，用来进行简单的自动化测试。你甚至可以使用装饰器从其他页面提取内容，例如输出到一些简单的门户容器。

从sitemesh-blank.war入手比较容易，但我建议学习 sitemesh-example.war 以获取更多的特性和思想。

不论你如何使用SiteMesh，我都发现它将大量的代码从表现层中移到我的装饰器中，而无需学习一种新的编程语言或是模版系统。

对了，作为最后的补充，如果你仍然对组合建立web页面感兴趣，可以查看home.worldonline.dk/viksoe/asmil.htm 。

祝好运并享受编程的乐趣！

Tag究竟是什么？如何实现一个Tag？ 
    一个tag就是一个普通的java类，它惟一特别之处是它必须继承TagSupport或者BodyTagSupport类。这两个类提供了一些方法，负责jsp页面和你编写的类之间的交互，例如输入，输出。而这两个类是由jsp容器提供的，无须开发人员自己实现。换句话说，你只需把实现了业务逻辑的类继承TagSupport或者BodyTagSupport，再做一些特别的工作，你的类就是一个Tag。并且它自己负责和jsp页面的交互，不用你多操心。

    “特别的工作”通常有以下几个步骤：

    1）提供属性的set方法，此后这个属性就可以在jsp页面设置。以jstl标签为例 c:out value=""/，这个value就是jsp数据到tag之间的入口。所以tag里面必须有一个setValue方法，具体的属性可以不叫value。例如setValue(String data){this.data = data;}
    这个“value”的名称是在tld里定义的。取什么名字都可以，只需tag里提供相应的set方法即可。

    2）处理 doStartTag 或 doEndTag 。这两个方法是 TagSupport提供的。 还是以c:out value=""/为例，当jsp解析这个标签的时候，在“<”处触发 doStartTag 事件，在“>”时触发 doEndTag 事件。通常在 doStartTag 里进行逻辑操作，在 doEndTag 里控制输出。
    3）编写tld文件。
    4）在jsp页面导入tld。这样，你的jsp页面就可以使用自己的tag了。

    通常你会发现自己绝大多数活动都集中在 doStartTag 或 doEndTag 方法里。确实如此，熟悉一些接口和类之后，写taglib很容易。正如《jsp设计》的作者所言：里面的逻辑稍微有点复杂，但毕竟没有火箭上天那么难。

    一个简单的例子：OutputTag

package diegoyun;
            import javax.servlet.jsp.JspException;
            import javax.servlet.jsp.JspWriter;
            import javax.servlet.jsp.tagext.TagSupport;
            /**
            * @author chenys
            */
            public class OutputTag extends TagSupport
            {
            private String name=null;
            public void setName(String name)
            {
            this.name = name;
            }
            public int doStartTag() throws JspException{
            try
            {
            JspWriter out = pageContext.getOut();
            out.print("Hello! " + name);
            }
            catch (Exception e)
            {
            throw new JspException(e);
            }
            return EVAL_PAGE;
            }
            }

<?xml version="1.0" encoding="ISO-8859-1" ?>
            <!DOCTYPE taglib
            PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN"
            "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd">
            <taglib>
            <tlib-version>1.0</tlib-version>
            <jsp-version>1.2</jsp-version>
            <short-name>diego</short-name>
            <!--OutputTag-->
            <tag>
            <name>out</name>
            <tag-class>diegoyun.OutputTag</tag-class>
            <body-content>empty</body-content>
            <attribute>
            <name>name</name>
            <required>false</required>
            <rtexprvalue>false</rtexprvalue>
            </attribute>
            </tag>
            </taglib>

<%@ page language="java"%>
            <%@ taglib uri="/WEB-INF/tlds/diego.tld" prefix="diego"%>
            <html>
            <body>
            Test Tag:
            <diego:out name="diegoyun"/>
            </body>
            </html>

• 1.先看这么一个例子

  <%@ page contentType="text/html; charset=gb2312" language="java"%>

  <%@ taglib uri="/WEB-INF/tlds/c.tld" prefix="c"%>

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

  <html>

  <body>

  <%

  String tut = "tutorial";

  request.setAttribute("tut",tut);

  %>

  The String in request is :

  <c:out value="${tut}"/>

  </body>

  </html>

  2.如何支持el表达式

  在路径org.apache.taglibs.standard.lang.support下，有个叫ExpressionEvaluatorManager.evaluate 的方法，当el表达式作为入参时，调用这个方法，在tag内即可自动把el表达式转化。例如，你想tag的value字段支持el表达式，那么只需在 set方法里如下调用：

  public void setValue(Object value)throws JspException

  {

      this.value = ExpressionEvaluatorManager.evaluate(

      "value", value.toString(), Object.class, this, pageContext);

  }

      ExpressionEvaluatorManager.evaluate有四个参数。第一个表示tag的名字，在取el表达式出错时使用。一般和属性名 字相同。第二个要求字符串，通常简单调用输入对象的toString方法。第三个是类，通常用Object.class。第四个用this即可，第五个是 pageContext变量。

  通常不用对这个方法思考太多。只需改改属性名字，其他照搬即可。

  注意：当你的tag属性支持el表达式时，你必须把它声明为Object对象。如上述的value，应该声明为：

  private Object value = null;

  3.实例：让OutputTag支持El表达式

  package diegoyun;

  import javax.servlet.jsp.JspException;

  import javax.servlet.jsp.JspWriter;

  import javax.servlet.jsp.tagext.TagSupport;

  import org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager;

• public class NewOutputTag extends TagSupport

  {

  private Object name = null;

  public void setName(Object name) throws JspException

  {

  this.name = ExpressionEvaluatorManager.evaluate(

  "name", name.toString(), Object.class, this, pageContext);

  }

  public int doStartTag() throws JspException{

  try

  {

  JspWriter out = pageContext.getOut();

  out.print("Hello! " + name);

  }

  catch (Exception e)

  {

  throw new JspException(e);

  }

  return EVAL_PAGE;

  }

  }

  在diego.tld里添加声明

  <!--NewOutputTag-->

  <tag>

  <name>newout</name>

  <tag-class>diegoyun.NewOutputTag</tag-class>

  <body-content>empty</body-content>

  <attribute>

  <name>name</name>

  <required>false</required>

  <rtexprvalue>true</rtexprvalue>

  </attribute>

  </tag>

  编写jsp测试

  <%@ page language="java" %>

  <%@ taglib uri="/WEB-INF/tlds/diego.tld" prefix="diego"%>

  <html>

  <body bgcolor="#FFFFFF">

  <%

  String s = "diego";

  request.setAttribute("name",s);

  %>

  Test El supported tag:

  <br>

  <diego:newout name="${name}"/>

  </body>

  </html>

  可以看到页面输出为：

  Test El supported tag:

  Hello! diego