集群配置（一）：Tomcat集群配置     相關(guān)文檔請參見各個工具相應(yīng)提供的文檔，工具的安裝此處不再介紹，默認(rèn)地，將Apache安裝在＄APACHE目錄，并將mod_jk-apache- 2.2.2.so改名為mod_jk.so放在＄APACHE/ modules下（注意JK與Apache httpd的版本關(guān)系），兩個Tomcat 的安裝路徑都在＄TOMCAT1和＄TOMCAT2。
    二、負(fù)載均衡
    1、基于request的負(fù)載均衡
    該 種方式下，負(fù)載均衡器 (load balancer)會根據(jù)各個node的狀況，把每個 http request進行分發(fā)。使用這樣的均衡策略，就必 須在多個節(jié)點之間復(fù)制用戶的session，實時保持整個集群的用 戶狀態(tài)同步，這種操作被稱為session復(fù)制 (session replication)。  
    該方法的優(yōu)點是客戶不會被綁定都具體的node，只要還有一個node存活，用戶狀態(tài)都不會丟失，cluster都能夠繼續(xù)工作。缺點是隨著節(jié)點的增加，可能會因廣播風(fēng)暴而導(dǎo)致性能大幅度下降
    2、 基于session的負(fù)載均衡
     該 種方式下，當(dāng)用戶發(fā)出第一個request后，負(fù)載均衡器動態(tài)的把該用戶分配到某個節(jié)點，并記錄該節(jié)點的jvm路由，以后該用戶的所有request 都會被綁定這個jvm路由，用戶只會與該server發(fā)生交互，這種策略被稱為粘性session(session sticky)。該方法的優(yōu)點是響應(yīng) 速度快，多個節(jié)點之間無須通信。缺點也很明顯，某個node死掉以后，它負(fù)責(zé)的所有用戶都會丟失session。
    3、Broker負(fù)載均衡
     將節(jié)點進行分片，每個分片組成一個對外的服務(wù)整體，在片內(nèi)使用基于request的負(fù)載均衡，而在片外使用基于session的負(fù)載均衡，使用這種處理將 使地Session復(fù)制的廣播保持為一個常量，不因為節(jié)點增加而導(dǎo)致性能下降，同時又保持高可靠性，不因為某個節(jié)點的崩潰而導(dǎo)致所有的Session數(shù)據(jù) 的丟失
    這里將著重介紹第一和第二種負(fù)載均衡的配置
    三、基于session的負(fù)載均衡
    1）Apache配置，在＄APACHE/conf/httpd.conf中增加如下配置：

以下內(nèi)容為程序代碼: # Load mod_jk module # Update this path to match your modules location LoadModule    jk_module  modules/mod_jk.so # Declare the module for <IfModule directive> (remove this line on Apache 2.x) #AddModule     mod_jk.c # Where to find workers.properties # Update this path to match your conf directory location (put workers.properties next to httpd.conf) JkWorkersFile conf/workers.properties # Where to put jk logs # Update this path to match your logs directory location (put mod_jk.log next to access_log) JkLogFile     jk/JK_LOG.txt # Set the jk log level [debug/error/info] JkLogLevel    info # Select the log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " # JkOptions indicate to send SSL KEY SIZE,  JkOptions     +ForwardKeySize +ForwardURICompat -ForwardDirectories # JkRequestLogFormat set the request format  JkRequestLogFormat     "%w %V %T" # Send everything for context /examples to worker named worker1 (ajp13) JkMount  /* loadbalancer

    2）在＄APACHE/conf/中創(chuàng)建workers.properties,內(nèi)容如下，關(guān)于Worker的詳細(xì)配置，請參見Jarkarta-Tomcat的Connector文檔

以下內(nèi)容為程序代碼: worker.list=loadbalancer,server2,server1 # Define the first node... worker.server2.port=8010 worker.server2.host=localhost worker.server2.type=ajp13 worker.server2.lbfactor=1 worker.server2.local_worker=1 worker.server2.cachesize=10 # Define the first node... worker.server1.port=8009 worker.server1.host=localhost worker.server1.type=ajp13 worker.server1.lbfactor=1 worker.server1.local_worker=1 worker.server1.cachesize=10 # Now we define the load-balancing behaviour worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=server1,server2 worker.loadbalancer.sticky_session=1

    在上面中，loadbalancer是一個虛擬Worker，并不代表任何節(jié)點，僅用于管理其他的Worker（注意其type為lb）
    3)兩個Tomcat的配置
    根據(jù)上面的workers.properties配置修改＄TOMCAT/conf/server.xml的端口配置，并修改
< Engine name="Catalina" defaultHost="localhost">為<Engine name= "Catalina" defaultHost="localhost" jvmRoute="server1/2">
    啟動Tomcat、Apache，到功告成
    四、基于request的負(fù)載均衡
    在如上配置的基礎(chǔ)上增加如下配置：
    1）workers.properties的worker.loadbalancer.sticky_session值改為0
    2）server.xml中的Cluster配置注釋去掉（注意端口，如果在同臺機上進行負(fù)載均衡，注意端口不要沖突）
    3）在應(yīng)用的web.xml中增加<distributable/>

 

WebWork+FreeMarker與JSF比較    WebWork 是一種傳統(tǒng)的MVC框架，其簡單而又不失強大，架構(gòu)非常靈活、擴展性強，完成最核心的功能也僅通過實現(xiàn)Action接口，而擴展的功能基本上可以通過其攔 截器結(jié)構(gòu)完成，另外，從WebWork2開始與ServletAPI的解耦也使其具備比較強的可測試性。然而其缺點也是非常地明顯，一方面其用戶群比較 少，缺少足夠文檔，另一方面，由于其開發(fā)團隊與Struts團隊合并以WebWork為核心開發(fā)新的MVC框架Struts Ti ， WebWork2.2已經(jīng)是其最終版本，缺乏后續(xù)版本的支持，而StrutsTi前途也還是個未知數(shù)。     JSF是JCP出品Sun力推的標(biāo) 準(zhǔn)，雖然出現(xiàn)較遲但可以說是來勢洶洶，大有想要一統(tǒng)MVC的架勢。JSF的優(yōu)點在于其標(biāo)準(zhǔn)，附帶而來的好處是豐富的JSF組件可供選擇，其另一個賣點是拖 拽式的界面開發(fā)模式。然而，其JSF本身架構(gòu)的復(fù)雜性足以讓人望而生畏，一方面，JSF組件的使用一旦出現(xiàn)問題非常難以調(diào)試，而其出錯信息往往沒有多少有 價值的東西，另一方面，一旦標(biāo)準(zhǔn)組件不能滿足需求需要獨立開發(fā)的話，難度非常高。    下面將對這兩種技術(shù)進行比較：     一、控制層：     1.耦合度     1)與ServletAPI的耦合       兩者都可以完全與ServletAPI的解耦，在開發(fā)時也都應(yīng)該盡量避免與ServletAPI的耦合     2)與框架API的耦合       WebWork:所有的控制類必須實現(xiàn)Action接口       JSF:FacesBean不需要繼承任何JSF接口。但有時需要與界面元素（譬如列表框）產(chǎn)生耦合，開發(fā)時應(yīng)該盡量將該部分隔離     評價：這兩種技術(shù)都是低耦合的，不相上下     2.IOC能力       WebWork本身提供了部分的IOC能力，但功能比較弱，已不被推薦。兩者都可以通過與Spring的結(jié)合獲 得IOC的能力，相對而言，JSF更簡單而且提供更多的功能。     評價：不相上下，JSF稍微勝出     3.AOP能力       WebWork:其攔截器功能本身就是一種AOP方式       JSF:可以通過與Spring的結(jié)合獲得AOP能力     評價：WebWork的AOP能力與WebWork的核心結(jié)合地更緊密，WebWork稍微勝出     4.配置       WebWork的配置本身不夠簡潔，而與Spring的結(jié)合更是出現(xiàn)重復(fù)的配置情況，相比而言，JSF更簡潔     評價：JSF勝出     5.可測試性       WebWork:WebWork本身的簡潔和靈活使其具備非常高的可測試性，可以脫離容器測試其控制層的行為       JSF:不清楚，似乎不能脫離容器獨立測試配置     評價：似乎是WebWork勝出     二、表現(xiàn)層：     1.組件化       FreeMarker:可以通過FreeMarker的宏能力將一些常用的組件，開發(fā)比較簡單，但同時，自己開發(fā)組件時間和質(zhì)量上可能無法保障       JSF:JSF本身就是為組件而生，由于其標(biāo)準(zhǔn)化，有豐富的組件可以使用，在項目的前期投入少，不需要專門開發(fā)組件     評價：隨著項目的開展，組件化的優(yōu)勢應(yīng)該會越來越明顯。在這點上，JSF壓倒性勝出     2.可調(diào)試性       FreeMarker:FreeMarker本身的出錯定位能力非常強，往往出錯信息非常直觀，但一旦進行組件包裝，可調(diào)試性將大打折扣       JSF:JSF的組件本身比較復(fù)雜，調(diào)試性差，往往很難根據(jù)出錯信息定位出錯情況，更多的時候需要依靠經(jīng)驗來解決     評價：FreeMarker稍勝出     3.擴展       FreeMarker:FreeMarker的宏功能非常簡單，功能擴展非常方便，但不足之處在于其邏輯表達能力比較差       JSF:JSF的組件的復(fù)雜性導(dǎo)致擴展新的功能是一個不小的代價，但Java語言強大的表達能力也使其能開發(fā)出復(fù)雜的功能     評價：FreeMarker稍勝出     4.表現(xiàn)邏輯能力       FreeMarker+WebWork:在WebWork的最新版本中提供了Ajax的客戶端驗證能力，但仍然比較原始       JSF:JSF有些客戶端驗證組件，但總的來說，仍然需要加強     評價：都比較差     5.Ajax       FreeMarker+WebWork:WebWork在最新版本中提供了Ajax支持，但包裝暫時還是比較原始       JSF:有各種具備Ajax特性的界面組件存在，同時可使用AjaxAnywhere提供更好的用戶體驗     評價：JSF稍勝出      從如上的比較可以看出，WebWork+FreeMarker和JSF可以說各有勝場，我的看法是，WebWork+FreeMarker具有更平緩的學(xué) 習(xí)曲線，使用比較簡單，在應(yīng)付小項目和小團隊上，略勝一籌；而面向大項目和大團隊，JSF的組件化在項目的進展中將發(fā)揮更大的作用。     除此之外，JSF的拖拽式的界面開發(fā)也是一個賣點，但我的看法是，對于一個熟手來說，其帶來的效率上的提高是微乎其微的，此外，一個提供這種功能的IDE，以下兩個問題是應(yīng)該考慮的：     1）對第三方JSF組件的支持     2）自動化生成的代碼的維護

在Hibernate3使用TreeCache

以下內(nèi)容為程序代碼: CREATE TESTUSER (    USERNAME VARCHAR(50) PRIMARY KEY,    PASSWORD VARCHAR(50) NOT NULL ); INSERT INTO TESTUSER(USERNAME, PASSWORD) VALUES ('ayufox0', '11');

     2.創(chuàng)建User類和hbm文件

以下內(nèi)容為程序代碼: package ayufox.hibernate.jbosscache; import java.io.Serializable; public class User implements Serializable { private String username; private String password; public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public boolean equals(Object obj) { if (obj instanceof User) { User u = (User) obj; return getUsername().equals(u.getUsername()); } else { return false; } } public int hashCode() { return getUsername().hashCode(); } }

以下內(nèi)容為程序代碼: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE hibernate-mapping PUBLIC      "-//Hibernate/Hibernate Mapping DTD 3.0//EN"     "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping package="ayufox.hibernate.jbosscache">     <class name="User" table="testuser">         <!-- TreeCache只支持read-only和transactional -->         <cache usage="transactional"/>         <id name="username">              <generator class="assigned"/>         </id>         <property name="password" not-null="true"/>     </class> </hibernate-mapping>

     3.Hibernate配置文件（hibernate.cfg.xml）

以下內(nèi)容為程序代碼: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"> <hibernate-configuration>     <session-factory>         <property name="hibernate.connection.url">jdbc:mysql://localhost:3306/test</property>         <property name="hibernate.connection.username">root</property>         <property name="hibernate.connection.password">11</property>         <property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>         <property name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property>         <property name="hibernate.show_sql">true</property>         <!-- 啟用TreeCache-->         <property name="hibernate.cache.provider_class">org.hibernate.cache.TreeCacheProvider</property>                  <mapping resource="ayufox/hibernate/jbosscache/User.hbm.xml"/>     </session-factory> </hibernate-configuration>

    4.TreeCache配置（treecache.xml，與hibernate.cfg.xml），更詳細(xì)配置請參見JBoss TreeCache文檔

以下內(nèi)容為程序代碼: <?xml version="1.0" encoding="UTF-8"?> <server>     <mbean code="org.jboss.cache.TreeCache"         name="jboss.cache:service=TreeCache">         <depends>jboss:service=Naming</depends>         <depends>jboss:service=TransactionManager</depends>         <attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute>         <attribute name="CacheMode">REPL_SYNC</attribute>         <attribute name="ClusterName">TreeCache-Cluster</attribute>         <attribute name="ClusterConfig">             <config>                 <UDP mcast_addr="228.1.2.3" mcast_port="48866"                     ip_ttl="64" ip_mcast="true"                      mcast_send_buf_size="150000" mcast_recv_buf_size="80000"                     ucast_send_buf_size="150000" ucast_recv_buf_size="80000"                     loopback="false"/>                 <PING timeout="2000" num_initial_members="3"                     up_thread="false" down_thread="false"/>                 <MERGE2 min_interval="10000" max_interval="20000"/>                 <FD_SOCK/>                 <VERIFY_SUSPECT timeout="1500"                     up_thread="false" down_thread="false"/>                 <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"                     max_xmit_size="8192" up_thread="false" down_thread="false"/>                 <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10"                     down_thread="false"/>                 <pbcast.STABLE desired_avg_gossip="20000"                     up_thread="false" down_thread="false"/>                 <FRAG frag_size="8192"                     down_thread="false" up_thread="false"/>                 <pbcast.GMS join_timeout="5000" join_retry_timeout="2000"                     shun="true" print_local_addr="true"/>                 <pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>             </config>         </attribute>     </mbean> </server>

   5. 例子代碼:通過其輸出的SQL代碼來看工作的正常情況
進程1：隔一段時間修改密碼

以下內(nèi)容為程序代碼: package ayufox.hibernate.jbosscache; import org.hibernate.Session; import org.hibernate.SessionFactory; import org.hibernate.Transaction; import org.hibernate.cfg.Configuration; public class Test1 { public static void main(String[] args) throws Exception { SessionFactory factory = new Configuration().configure() .buildSessionFactory(); int index = 0; while (true) { Session session = factory.openSession(); if (index % 5 == 0) { Transaction tx = session.beginTransaction(); User u = (User) session.load(User.class, "ayufox0"[img]/images/wink.gif[/img]; u.setPassword(new Long(System.currentTimeMillis()).toString()); session.update(u); tx.commit(); u = null; } else { User u = (User) session.load(User.class, "ayufox0"[img]/images/wink.gif[/img]; System.out.println("password:" + u.getPassword()); } index++; session.close(); Thread.sleep(5000); } } }

進程2：隔一段時間讀取密碼

以下內(nèi)容為程序代碼: package ayufox.hibernate.jbosscache; import java.text.SimpleDateFormat; import java.util.Date; import org.hibernate.Session; import org.hibernate.SessionFactory; import org.hibernate.cfg.Configuration; public class Test2 { private final static SimpleDateFormat FORMAT = new SimpleDateFormat( "HH:mm:ss"[img]/images/wink.gif[/img]; public static void main(String[] args) throws Exception { SessionFactory factory = new Configuration().configure() .buildSessionFactory(); while (true) { Session session = factory.openSession(); User u = (User) session.load(User.class, "ayufox0"[img]/images/wink.gif[/img]; System.out.println("date:" + FORMAT.format(new Date(new Long(u.getPassword())))); u = null; session.close(); Thread.sleep(5000); } } } 2006-7-21 JBossCache-TreeCache體驗     TreeCache 是一種結(jié)構(gòu)化的、基于復(fù)制的事務(wù)緩存。TreeCache是JBoss應(yīng)用服務(wù)器中集群服務(wù)—包括JNDI集群、HTTP和EJB的Sesssion集 群、JMS集群—的基礎(chǔ)框架。其可以單獨使用，可以集成到JBossAS應(yīng)用，也可以集成到其他的應(yīng)用服務(wù)器上。TreeCache是一種樹狀結(jié)構(gòu)，每個 節(jié)點擁有一個名字和多個或者沒有子節(jié)點，除跟節(jié)點沒有子節(jié)點其他節(jié)點有且只有一個父母節(jié)點，可以通過路徑名來訪問子節(jié)點（FQN： Full Qualified Name），在一個TreeCache中可以存在多棵樹，，即可以有多個根節(jié)點。當(dāng)應(yīng)用于分布式環(huán)境時，由于 TreeCache是基于復(fù)制的，每個子節(jié)點的值必須是可序列化的。      在下面中，將通過例子來了解TreeCache的功能及其配置，使 用JBossCache1.4和JDK5.0。首先是一個最基本使用TreeCache的程序例子并配置一個TreeCache的配置骨架（各種常用的配 置可參見jboss-cache-dist-1.4.0.CR1版本的etc目錄，如下各種配置參考也可見該目錄下的范例配置，以下不再強調(diào)），見下： 以下內(nèi)容為程序代碼: TreeCache tree = new TreeCache(); tree.setClusterProperties("treecache.xml"[img]/images/wink.gif[/img];  tree.createService();  tree.startService();  tree.put("/a/b/c", "name", "Ben"[img]/images/wink.gif[/img]; tree.put("/a/b/c/d", "uid", new Integer(322649)); Integer tmp = (Integer) tree.get("/a/b/c/d", "uid"[img]/images/wink.gif[/img]; tree.remove("/a/b"[img]/images/wink.gif[/img]; tree.stopService(); tree.destroyService();  以下內(nèi)容為程序代碼: treecache.xml： <server>     <mbean code="org.jboss.cache.TreeCache"         name="jboss.cache:service=TreeCache">         <depends>jboss:service=Naming</depends>         <depends>jboss:service=TransactionManager</depends>         <attribute name="ClusterName">TreeCache-Cluster</attribute>         <attribute name="ClusterConfig">             <config>                 <UDP mcast_addr="228.1.2.3" mcast_port="48866"                     ip_ttl="64" ip_mcast="true"                      mcast_send_buf_size="150000" mcast_recv_buf_size="80000"                     ucast_send_buf_size="150000" ucast_recv_buf_size="80000"                     loopback="false"/>                 <PING timeout="2000" num_initial_members="3"                     up_thread="false" down_thread="false"/>                 <MERGE2 min_interval="10000" max_interval="20000"/>                 <FD_SOCK/>                 <VERIFY_SUSPECT timeout="1500"                     up_thread="false" down_thread="false"/>                 <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"                     max_xmit_size="8192" up_thread="false" down_thread="false"/>                 <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10"                     down_thread="false"/>                 <pbcast.STABLE desired_avg_gossip="20000"                     up_thread="false" down_thread="false"/>                 <FRAG frag_size="8192"                     down_thread="false" up_thread="false"/>                 <pbcast.GMS join_timeout="5000" join_retry_timeout="2000"                     shun="true" print_local_addr="true"/>                 <pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>             </config>         </attribute>     </mbean> </server>      其中ClusterConfig配置在前面JavaGroups的介紹詳細(xì)介紹，其它配置比較簡單，需要進一步了解請參見TreeCache文檔。      一、Cache分類      TreeCache 按功能分為三類：本地(Local)Cache、復(fù)制(Replication)Cache和失效(Invalidation)Cache。本地 Cache只應(yīng)用于本地環(huán)境，后兩個Cache可應(yīng)用于分布式環(huán)境，其中，在分布式環(huán)境中，復(fù)制Cache當(dāng)一個Cache實例的一個節(jié)點值發(fā)生變化時會 將變化復(fù)制到其它實例中，而失效Cache是當(dāng)一個Cache實例的一個節(jié)點值發(fā)生變化時會將其它實例的相應(yīng)節(jié)點的值設(shè)為空，讓其重新去獲得該值，可通過 這種方式緩存大對象以減少在實例中復(fù)制對象的代價。分布式Cache（復(fù)制和失效Cache）又分為兩種，同步（REPL_ASYNC）和異步 （REPL_SYNC），同步Cache是在一個Cache實例做修改時，等待變化應(yīng)用到其它實例后才返回，而異步Cache是在一個Cache實例做修 改時，即刻返回。其配置見下： 以下內(nèi)容為程序代碼: <!--    Valid modes are LOCAL                    REPL_ASYNC                    REPL_SYNC                    INVALIDATION_ASYNC                    INVALIDATION_SYNC --> <attribute name="CacheMode">REPL_SYNC</attribute>      二、事務(wù)和并行(Transaction And Concurrent)      TreeCache 是一種事務(wù)Cache，與JDBC一樣，其包括兩方面內(nèi)容：鎖和隔離級別。鎖分為悲觀鎖和樂觀鎖，當(dāng)使用悲觀鎖時，分為五個隔離級別，分別是 SERIALIZABLE、REPEATABLE_READ (default)、READ_COMMITTED、READ_UNCOMMITTED和 NONE，隔離級別逐步減弱。樂觀鎖也叫版本鎖，其對數(shù)據(jù)進行操作時，將其復(fù)制到臨時區(qū)，操作之后將版本與原有數(shù)據(jù)比較，如果一致則將遞增版本并寫回，如 果不一致則回滾，由于樂觀鎖僅在復(fù)制出數(shù)據(jù)和提交數(shù)據(jù)時對數(shù)據(jù)加鎖，所以并行度更高，但如果寫操作比較頻繁地話則容易出現(xiàn)沖突導(dǎo)致回滾。 TreeCache默認(rèn)使用悲觀鎖。使用TreeCache時，需要使用容器提供的事務(wù)管理器，一般使 JBossTransactionManagerLookup和GenericTransactionManagerLookup，前者應(yīng)用于JBOSS 服務(wù)器，后者應(yīng)用于其他服務(wù)器，也可使用DummyTransactionManagerLookup用于測試。如上介紹的配置如下： 以下內(nèi)容為程序代碼:        <attribute name="NodeLockingScheme">OPTIMISTIC</attribute>        <attribute name="IsolationLevel">REPEATABLE_READ</attribute>       <attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute>      三、逐出策略(Eviction Policy)       由于內(nèi)存數(shù)量的局限，不可能將所有的Cache數(shù)據(jù)存放在內(nèi)存中，但使用內(nèi)存達到一定極限時，會將部分?jǐn)?shù)據(jù)清除出內(nèi)存，保存到其它持久媒質(zhì)中，定義的什么 時候清除、如何清除的策略就是逐出策略。自定義一個逐出策略需要實現(xiàn)org.jboss.cache.eviction.EvictionPolicy、 org.jboss.cache.eviction.EvictionAlgorithm、 org.jboss.cache.eviction.EvictionQueue  和org.jboss.cache.eviction.EvictionConfiguration四個接口，系統(tǒng)提供了LRU (Least recently used，最近最少使用)、LFU(Least Frequently Used最不經(jīng)常使用)、FIFO (First In First Out先進先出)、MRU(Most Recently Used最近最經(jīng)常使用)四種實現(xiàn)，詳細(xì)參見 org.jboss.cache.eviction包的源代碼。配置如下： 以下內(nèi)容為程序代碼: <attribute name="EvictionPolicyConfig">    <config>       <attribute name="wakeUpIntervalSeconds">5</attribute>       <region name="/_default_">         <attribute name="maxNodes">5000</attribute>         <attribute name="timeToLiveSeconds">1000</attribute>       </region>       <region name="/org/jboss/data" policyClass="org.jboss.cache.eviction.FIFOPolicy">         <attribute name="maxNodes">5000</attribute>       </region>       <region name="/test/" policyClass="org.jboss.cache.eviction.MRUPolicy">         <attribute name="maxNodes">10000</attribute>       </region>       <region name="/maxAgeTest/">         <attribute name="maxNodes">10000</attribute>         <attribute name="timeToLiveSeconds">8</attribute>         <attribute name="maxAgeSeconds">10</attribute>       </region>    </config> </attribute>      也可以多對所有的區(qū)域定義同樣的逐出策略 以下內(nèi)容為程序代碼: <attribute name="EvictionPolicyClass">org.jboss.cache.eviction.LFUPolicy</attribute>      四、Cache加載     由于逐出策略的存在，那么當(dāng)我們重新需要獲得一個原來在緩存中但確由內(nèi)存原因被逐出的數(shù)據(jù)時，就需要定義一種加載策略，使地可以重新找回數(shù)據(jù)，同時，Cache加載也肩負(fù)在將數(shù)據(jù)逐出時將數(shù)據(jù)保存到持久媒質(zhì)的責(zé)任。     根據(jù)將數(shù)據(jù)保存媒質(zhì)的不同，Cache加載包括FileCacheLoader、JDBCCacheLoader等等，可以同時使用多種加載器來靈活定制加載策略。例見下： 以下內(nèi)容為程序代碼: <attribute name="CacheLoaderConfiguration">     <config>         <passivation>false</passivation>         <preload>/</preload>         <shared>true</shared>         <cacheloader>             <class>org.jboss.cache.loader.ClusteredCacheLoader</class>             <properties>                  timeout=1000             </properties>             <async>true</async>             <fetchPersistentState>false</fetchPersistentState>             ignoreModifications>false</ignoreModifications>             <purgeOnStartup>false</purgeOnStartup>         </cacheloader>         <cacheloader>             <class>org.jboss.cache.loader.JDBCCacheLoader</class>             <properties>                         cache.jdbc.table.name=jbosscache                         cache.jdbc.table.create=true                         cache.jdbc.table.drop=true                         cache.jdbc.table.primarykey=jbosscache_pk                         cache.jdbc.fqn.column=fqn                         cache.jdbc.fqn.type=varchar(255)                         cache.jdbc.node.column=node                         cache.jdbc.node.type=longblob                         cache.jdbc.parent.column=parent                         cache.jdbc.driver=com.mysql.jdbc.Driver                         cache.jdbc.url=jdbc:mysql://localhost:3306/jbossdb                         cache.jdbc.user=root                         cache.jdbc.password=              </properties>              <async>true</async>              <fetchPersistentState>false</fetchPersistentState>              <purgeOnStartup>false</purgeOnStartup>          </cacheloader>     </config> </attribute>     我們將通過定制如上的配置信息以更有效地使用JBossCache。詳細(xì)情況可參考JBoss TreeCache參考文檔和范例。 2006-7-19 JavaGroups—構(gòu)建分布式通信的基礎(chǔ)（下） 以下內(nèi)容為程序代碼: public interface MessageListener {    void receive(Message msg);    byte[] getState();    void setState(byte[] state); }     2)ExtendedMessageListener：擴展消息監(jiān)聽器 以下內(nèi)容為程序代碼: public interface ExtendedMessageListener extends MessageListener {    byte[] getState(String state_id);    void setState(String state_id, byte[] state); }     3)MemberShipListener：成員監(jiān)聽器 以下內(nèi)容為程序代碼: public interface MembershipListener {    void viewAccepted(View new_view);    void suspect(Object suspected_mbr);    void block(); }    4)ChannelListener：通道監(jiān)聽器 以下內(nèi)容為程序代碼: public interface ChannelListener {    void channelConnected(Channel channel);    void channelDisconnected(Channel channel);    void channelClosed(Channel channel);    void channelShunned();    void channelReconnected(Address addr); }    5)Receiver：接受者 以下內(nèi)容為程序代碼: public interface Receiver extends MessageListener, MembershipListener { }    6)ExtendedReceiver：擴展接受者 以下內(nèi)容為程序代碼: public interface ExtendedReceiver extends ExtendedMessageListener, MembershipListener { } 示例如下： 以下內(nèi)容為程序代碼: JChannel ch=new JChannel(); ch.setReceiver(new ExtendedReceiverAdapter() {   public void receive(Message msg) {     System.out.println("received message " + msg);   }   public void viewAccepted(View new_view) {     System.out.println("received view " + new_view);   } }); ch.connect("bla"[img]/images/wink.gif[/img];    在通道同時擔(dān)當(dāng)接受者和發(fā)送者時需要創(chuàng)建至少兩個線程分擔(dān)兩個不同的工作，通過向Jchannel注冊一個接受者（Receiver），使我們不需要自己顯式地創(chuàng)建接受線程    二、高層組件：以下類位于org.jgroups.blocks包下    使用JavaGroups的基本接口和通道編程比較直接而直觀，缺點是編程有時過于繁雜，JavaGroups為我們提供了一些高層的組件降低編程的難度。（以下類位于org.jgroups.blocks包下）    1．拉推模式適配器（PullPushAdapter）    一般直接使用Jchannel，是采用拉的方式，即用戶自己編程去“推動”接收和發(fā)送信息，通過該適配器，即轉(zhuǎn)換為由用戶注冊一個Listener，由適配器去“推動“接收和發(fā)送信息，例： 以下內(nèi)容為程序代碼: public class PullPushTest implements MessageListener {    Channel channel;    PullPushAdapter adapter;    byte[] data="Hello world".getBytes();    public void receive(Message msg) {       System.out.println("Received msg: " + msg);    }    public void start() throws Exception {       channel=new JChannel();       channel.connect("PullPushTest"[img]/images/wink.gif[/img];       adapter=new PullPushAdapter(channel);       adapter.setListener(this);       for(int i=0; i < 10; i++) {          System.out.println("Sending msg #" + i);          channel.send(new Message(null, null, data));          Thread.currentThread().sleep(1000);       }       adapter.stop();       channel.close();    }    public static void main(String args[]) {       try {          new PullPushTest().start();       }       catch(Exception e) { /* error */ }    } }    2．信息分發(fā)器(MessageDispatcher)     Jchannel是采用異步的方式接受信息的，如果想使用同步接受信息，可使用該類，當(dāng)然，該類也可用于異步接受信息，由于該類內(nèi)部使用了PullPushAdapter，所以其也是“推“模式。例見下： 以下內(nèi)容為程序代碼: public class MessageDispatcherTest implements RequestHandler {    Channel channel;    MessageDispatcher disp;    RspList rsp_list;    public void start() throws Exception {       channel=new JChannel();       disp=new MessageDispatcher(channel, null, null, this);       channel.connect("MessageDispatcherTestGroup"[img]/images/wink.gif[/img];       for(int i=0; i < 10; i++) {           Thread.sleep(100);           System.out.println("Casting message #" + i);           rsp_list=disp.castMessage(null,              new Message(null, null, new String("Number #" + i)),                          GroupRequest.GET_ALL, 0);//GET_ALL表示等待所有信息發(fā)完           System.out.println("Responses:\n" +rsp_list);       }       channel.close();       disp.stop();    }    public Object handle(Message msg) {       System.out.println("handle(): " + msg);       return new String("Success !"[img]/images/wink.gif[/img];    }    public static void main(String[] args) {       try {          new MessageDispatcherTest().start();       }       catch(Exception e) {          System.err.println(e);       }    } }    看看每次操作的返回結(jié)果RspList類的聲明 以下內(nèi)容為程序代碼: public class RspList {    public boolean isReceived(Address sender);    public int numSuspectedMembers();    public Vector getResults();    public Vector getSuspectedMembers();    public boolean isSuspected(Address sender);    public Object get(Address sender);    public int size();    public Object elementAt(int i) throws ArrayIndexOutOfBoundsException; }    其保存了每條信息的操作結(jié)果情況    3．RPC分發(fā)器（RpcDispatcher）    RPC用戶遠程與本地相同的對象的方法調(diào)用，見下面例子： [code] public class RpcDispatcherTest {    Channel channel;    RpcDispatcher disp;    RspList rsp_list;    public int print(int number) throws Exception {       return number * 2;    }    public void start() throws Exception {       channel=new JChannel(props);       disp=new RpcDispatcher(channel, null, null, this);       channel.connect("RpcDispatcherTestGroup"[img]/images/wink.gif[/img];       for(int i=0; i < 10; i++) {           Thread.sleep(100);           rsp_list=disp.callRemoteMethods(null, "print",                  new Integer(i), GroupRequest.GET_ALL, 0);           System.out.println("Responses: " +rsp_list);       }       channel.close();       disp.stop();    }    public static void main(String[] args) {       try {           new RpcDispatcherTest().start();       }       catch(Exception e) {           System.err.println(e);       }    } } 三、分布式數(shù)據(jù)結(jié)構(gòu)：     使用分布式數(shù)據(jù)結(jié)構(gòu)可以在多個進程的內(nèi)部保持?jǐn)?shù)據(jù)結(jié)構(gòu)的多個實例，在任何時刻每個實例都有相同的值，主要有DistributedHashtable、ReplicatedHashtable和DistributedTree，其使用比較直接，此處不再做詳細(xì)舉例 參考：《JGroups文檔》 2006-7-17 JavaGroups—構(gòu)建分布式通信的基礎(chǔ)（上）    JavaGroups 是一種可靠組通信工具，在同一個臺主機、局域網(wǎng)甚至是廣域網(wǎng)中，組成員可以加入一個組，發(fā)送消息給其它的組成員并從其它成員中接收消息，系統(tǒng)跟蹤所有組成 員加入、退出和崩潰，并將這些系統(tǒng)信息發(fā)送給其它組成員。在JavaGroups中，組并不需要明確地創(chuàng)建，當(dāng)?shù)谝粋€成員加入一個組時，自動創(chuàng)建了該組， 第一個成員同時作為系統(tǒng)的協(xié)調(diào)者統(tǒng)一發(fā)送系統(tǒng)信息（譬如成員的加入退出等）給其它成員，而其他組成員通過與系統(tǒng)協(xié)調(diào)者的通信來獲得系統(tǒng)的變化情況。目前大 部分開源的分布式緩存的底層都是基于JGroups，包括鼎鼎大名的JBossCache、OSCache等等。      上圖為JavaGroups的概念架構(gòu)圖。可以看出，JavaGroups從概念上自下而上分為三個部分，協(xié)議棧、通道(Channel接口)、 BuildingBlocks And DistributedDataStructures （高層組件和分布式數(shù)據(jù)結(jié)構(gòu)）和應(yīng)用程序。其中，通道、高 層組件和分布式數(shù)據(jù)結(jié)構(gòu)是系統(tǒng)暴露出來的接口，用戶應(yīng)用程序通過與該部分的交互來使用底層的通信功能。以下將分別對各部分進行詳細(xì)介紹。      協(xié)議棧是系統(tǒng)最核心的部分，其定義了組成員之間如何通信、協(xié)調(diào)，組如何初始化，組如何檢測成員等等最核心和根本的功能。協(xié)議棧是一些有順序的協(xié)議的組合， 當(dāng)通道發(fā)送一條消息時，首先將其傳遞給協(xié)議棧(Protocol stack),協(xié)議棧將其傳遞給最頂端的協(xié)議處理,每個協(xié)議處理完之后將其傳遞給其底端 協(xié)議處理，最后，最底端的協(xié)議將消息通過網(wǎng)絡(luò)將其傳送出去。     下圖是一個協(xié)議堆例子，其中：CAUSAL協(xié)議定義了一個組成員順序發(fā)送出去 的消息必須按相同的順序被其它的組成員所接受；GMS協(xié)議定義了組管理服務(wù)，包括成員的加入、離開和崩潰的處理；MERGE協(xié)議定義了子組的合并，即協(xié)調(diào) 者定期廣播一些HELLO和地址信息，如果接受到回應(yīng)和其組名一致并且目前還沒加入本組，則將其合并進來；FRAG定義了消息分楨機制，即當(dāng)一個消息超過 一定大小的時候?qū)⑵浞纸鉃閹讉€小消息發(fā)送；UDP定義了底層的傳送機制。協(xié)議棧靈活的定義機制使用戶可以靈活地根據(jù)自己的需求來定義使用的協(xié)議棧。     下面列出一些常用的協(xié)議的作用:     1)核心微協(xié)議 CAUSAL：組中消息的原因排序。實現(xiàn)使用一個矢量時鐘 FD：使用 heartbeat 協(xié)議的故障檢測。根據(jù)成員關(guān)系列表中的排序，Heartbeat 消息被發(fā)送到鄰居成員 FD_SOCK：基于 TCP 套接字的故障檢測。基于環(huán) 的 ping 被在鄰居成員之間發(fā)送。當(dāng)所有成員都在同一物理主機上時工作得最好 FD_PID： 使用進程 ID 的故障檢測 (本地 JNI 代碼，以獲得所需的 PID)。只能在同一臺主機上 (一個 IP 地址) 工作 FD_PROB： 使用隨機算法的故障檢測。組的每個成員發(fā)送 heartbeat，并維護其他成員的 heartbeat 計數(shù) FLOW_CONTROL：流控制實現(xiàn)，限制了消息收據(jù)之間發(fā)送的消息的最大數(shù)量 FLUSH：以一致的方式跨所有成員清除所有的消息。通常是在視圖更改之前執(zhí)行 FRAG：消息分段和重新裝配（Message fragmentation and reassembly）。確保較大的消息在沿著棧往下發(fā)送之前被分為  FRAG_SIZE：大小的段。分段的消息在沿著棧往上發(fā)送之前在接收方被重新裝配 GMS：組管理服務(wù)?；谔摂M同步模型管理組成員關(guān)系 MERGEMERGE2：合并分離的子組。當(dāng)網(wǎng)絡(luò)由于故障而分離成多個部分時就形成了子組 NACKACK：實現(xiàn)可靠的傳輸?；谙⑿蛄刑栒埱髞G失消息的重新傳輸。確保從每個起始通道發(fā)出的消息的正確排序JMS將 Java Message Service 用于傳輸。與任何 JMS 實現(xiàn)協(xié)同工作 STATE_TRANSFER： 實現(xiàn)狀態(tài)傳輸協(xié)議，使得新成員可以從同等物（coordinator）或所有成員獲得現(xiàn)有的狀態(tài)。需要 FLUSH 微協(xié)議在協(xié)議棧上 UNICAST：實現(xiàn)可靠的單播傳輸。請求丟失消息的重新傳輸，并確保發(fā)出消息的正確排序 VIEW_ENFORCER：直到接收到第一個  VIEW_CHANGE： 才丟棄消息?？蛻舳酥挥性诔蔀榻M成員后才需要處理消息 STABLE：實現(xiàn)分布式的垃圾收集協(xié)議 (也就是說，刪除所有已被所有組成員接收到的消息) VERIFY_SUSPECT：發(fā)送消息以確保以前懷疑的成員已真正崩潰（crashed） UDP：一般用作組消息傳輸?shù)淖畹蛯印P 多播用于組廣播，而 UDP 用于點到點通信PING：用于引導(dǎo)成員關(guān)系管理。使用 IP 多播 "ping" 消息來定位成員，然后再請求這       些成員加入組中     2)基于隨機廣播的微協(xié)議 pbcast.GMS：組管理服務(wù)，基于隨機廣播 (雜談)。不需要 FLUSH pbcast.FD：基于雜談（gossip） 的被動故障檢測。不發(fā)送 heartbeat 消息 pbcast.PBCAST：實現(xiàn)隨機廣播，有規(guī)律地以雜談的方式發(fā)送到成員關(guān)系的一個隨機子集 pbcast.STABLE：實現(xiàn)分布式的垃圾收集協(xié)議 (也就是說，刪除所有已被所有組成員接收到的消息) pbcast.NAKACK：對丟失消息的重新傳輸和消息的順序傳送的否認(rèn)實現(xiàn)pbcast.STATE_TRANSFER：將隨機廣播用于狀態(tài)傳輸實現(xiàn)。不需要 QUEUE     3)穿越 WAN 和防火墻的微協(xié)議 TCP ：用于取代 UDP 作為最低層傳輸。通過 TCP 連接發(fā)送多個單播消息到成員，而不是發(fā)送多播消息 (不可能)。已經(jīng)內(nèi)置了可靠性、FIFO 排序和流控制 TCPPING：使用一組已知的成員來引導(dǎo)通過 TCP 的成員關(guān)系管理 TCPGOSSIP：使用一個外部雜談 (參見 參考資料) 服務(wù)器，來為成員關(guān)系管理的引導(dǎo)定位成員的初始集合  TUNNEL： 當(dāng)用于代替 UDP 或 TCP 作為最低層傳輸協(xié)議時，啟用通過防火墻的隧道技術(shù)。與防火墻外的一個 JavaGroups Router 進程協(xié)同工作     JavaGroups中所有的協(xié)議都在org.jgroups.protocol包及其自包中定義，各協(xié)議詳細(xì)的定義和實現(xiàn)可參見源代碼。      通道類似于Socket，用戶通過通道與底層的交互，使用編程更加方便。通道相當(dāng)于一個組的句柄，對用戶而言，組通信最核心的功能是加入組、退出組、發(fā)送 消息、接收消息，都通過通道來達到這個目的，即org.jgroups.Channel的實現(xiàn)。值得注意的是，JavaGroups中Channel僅是 一個抽象類，可以使用不同的通道實現(xiàn)，見下圖：     在這里我們僅探討最常用的org.jgroups.Jchannel實現(xiàn)。     1）指定協(xié)議棧并創(chuàng)建通道，并連接到一個組 以下內(nèi)容為程序代碼: String props = "UDP(mcast_addr=228.8.8.8;mcast_port=45566;ip_ttl=32;"    + "mcast_send_buf_size=64000;mcast_recv_buf_size=64000):"    + "PING(timeout=2000;num_initial_members=3):"    + "MERGE2(min_interval=5000;max_interval=10000):"    + "FD_SOCK:"    + "VERIFY_SUSPECT(timeout=1500):"    + "pbcast.NAKACK(max_xmit_size=8096;gc_lag=50;retransmit_timeout=600,1200,2400,4800):"    + "UNICAST(timeout=600,1200,2400,4800):"    + "pbcast.STABLE(desired_avg_gossip=20000):"    + "FRAG(frag_size=8096;down_thread=false;up_thread=false):"  + "pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;"    + "shun=false;print_local_addr=true):" + "STATE_TRANSFER:QUEUE"; JChannel channel = new JChannel(props); channel.connect(“groupname”);      2)發(fā)送一條消息 以下內(nèi)容為程序代碼: channel.send(new Message(null, null, “Hello, JavaGroups”);      3)接受一條消息 以下內(nèi)容為程序代碼: Object obj = channel.receive(0);       4）退出組 以下內(nèi)容為程序代碼: channel.close();      可以通過設(shè)置通道的一些選項來定義通道的行為      public void setOpt(int option, Object value)      目前有效的值分別是      1）Channel.BLOCK：是否接受阻塞信息，默認(rèn)為Boolean.TRUE      2）Channel.LOCAL：消息廣播時，消息發(fā)送者是否也會接受到該消息，默認(rèn)為Boolean.TRUE      3）Channel.AUTO_RECONNECT：通道斷開時是否自動重連接，默認(rèn)值為Boolean.TRUE      4）Channel.AUTO_GETSTATE：是否自動重新獲得狀態(tài)信息，默認(rèn)值為Boolean.TRUE      系統(tǒng)以及組成員之間通過消息的方式來進行通信，消息分為如下幾種（以下說明的類位于org.jgroups包下）：      1）普通消息(Message類)      用戶組成員之間的交互消息，包括消息頭、消息接受者、消息發(fā)送者和消息體      2）視圖(View類)      即組成員的情況，當(dāng)一個成員加入、退出或者崩潰時，系統(tǒng)協(xié)調(diào)者（見上，第一個組成員）向其它發(fā)送新的視圖信息      3）疑似事件（SuspectEvent類）      當(dāng)檢測到一個組成員可能已經(jīng)離開或者崩潰時，發(fā)送該信息。      4）阻塞事件（BlockEvent類）      當(dāng)系統(tǒng)協(xié)調(diào)者在更新視圖時，會發(fā)送該阻塞信息給其它組成員，讓其在視圖更新之后再做發(fā)送消息的操作      5）獲得狀態(tài)事件（GetStateEvent類）      6）設(shè)置狀態(tài)事件（SetStateEvent類）      應(yīng)用程序可能需要保持一些狀態(tài)，并在各個成員之間同步，可以通過這兩個事件知曉狀態(tài)的變化      就此，我們已經(jīng)對JavaGroups的架構(gòu)和組件有一個基本的了解，下部分將通過例子進一步介紹JavaGroups的使用 2006-7-14 對象的強、軟、弱和虛引用 (摘)     在JDK1.2以前的版本中，當(dāng)一個對象不被任何變量引用，那么程序就無法再使用這個對象。也就是說，只有對象處于可觸及狀態(tài)，程序才能使用它。這就像在 日常生活中，從商店購買了某樣物品后，如果有用，就一直保留它，否則就把它扔到垃圾箱，由清潔工人收走。一般說來，如果物品已經(jīng)被扔到垃圾箱，想再把它撿 回來使用就不可能了。 但有時候情況并不這么簡單，你可能會遇到類似雞肋一樣的物品，食之無味，棄之可惜。這種物品現(xiàn)在已經(jīng)無用了，保留它會占空 間，但是立刻扔掉它也不劃算，因為也許將來還會派用場。對于這樣的可有可無的物品，一種折衷的處理辦法是：如果家里空間足夠，就先把它保留在家里，如果家 里空間不夠，即使把家里所有的垃圾清除，還是無法容納那些必不可少的生活用品，那么再扔掉這些可有可無的物品。     從JDK1.2版本開始，把對象的引用分為四種級別，從而使程序能更加靈活的控制對象的生命周期。這四種級別由高到低依次為：強引用、軟引用、弱引用和虛引用。     1．強引用      本章前文介紹的引用實際上都是強引用，這是使用最普遍的引用。如果一個對象具有強引用，那就類似于必不可少的生活用品，垃圾回收器絕不會回收它。當(dāng)內(nèi)存空 間不足，Java虛擬機寧愿拋出OutOfMemoryError錯誤，使程序異常終止，也不會靠隨意回收具有強引用的對象來解決內(nèi)存不足問題。     2．軟引用（SoftReference）     如果一個對象只具有軟引用，那就類似于可有可物的生活用品。如果內(nèi)存空間足夠，垃圾回收器就不會回收它，如果內(nèi)存空間不足了，就會回收這些對象的內(nèi)存。只要垃圾回收器沒有回收它，該對象就可以被程序使用。軟引用可用來實現(xiàn)內(nèi)存敏感的高速緩存。     軟引用可以和一個引用隊列（ReferenceQueue）聯(lián)合使用，如果軟引用所引用的對象被垃圾回收，Java虛擬機就會把這個軟引用加入到與之關(guān)聯(lián)的引用隊列中。     3．弱引用（WeakReference）      如果一個對象只具有弱引用，那就類似于可有可物的生活用品。弱引用與軟引用的區(qū)別在于：只具有弱引用的對象擁有更短暫的生命周期。在垃圾回收器線程掃描它 所管轄的內(nèi)存區(qū)域的過程中，一旦發(fā)現(xiàn)了只具有弱引用的對象，不管當(dāng)前內(nèi)存空間足夠與否，都會回收它的內(nèi)存。不過，由于垃圾回收器是一個優(yōu)先級很低的線程， 因此不一定會很快發(fā)現(xiàn)那些只具有弱引用的對象。     弱引用可以和一個引用隊列（ReferenceQueue）聯(lián)合使用，如果弱引用所引用的對象被垃圾回收，Java虛擬機就會把這個弱引用加入到與之關(guān)聯(lián)的引用隊列中。     4．虛引用（PhantomReference）     "虛引用"顧名思義，就是形同虛設(shè)，與其他幾種引用都不同，虛引用并不會決定對象的生命周期。如果一個對象僅持有虛引用，那么它就和沒有任何引用一樣，在任何時候都可能被垃圾回收。 虛 引用主要用來跟蹤對象被垃圾回收的活動。虛引用與軟引用和弱引用的一個區(qū)別在于：虛引用必須和引用隊列（ReferenceQueue）聯(lián)合使用。當(dāng)垃圾 回收器準(zhǔn)備回收一個對象時，如果發(fā)現(xiàn)它還有虛引用，就會在回收對象的內(nèi)存之前，把這個虛引用加入到與之關(guān)聯(lián)的引用隊列中。程序可以通過判斷引用隊列中是否 已經(jīng)加入了虛引用，來了解被引用的對象是否將要被垃圾回收。程序如果發(fā)現(xiàn)某個虛引用已經(jīng)被加入到引用隊列，那么就可以在所引用的對象的內(nèi)存被回收之前采取 必要的行動。     在本書中，"引用"既可以作為動詞，也可以作為名詞，讀者應(yīng)該根據(jù)上下文來區(qū)分"引用"的含義。 在java.lang.ref 包中提供了三個類：SoftReference類、WeakReference類和PhantomReference類，它們分別代表軟引用、弱引用和虛 引用。ReferenceQueue類表示引用隊列，它可以和這三種引用類聯(lián)合使用，以便跟蹤Java虛擬機回收所引用的對象的活動。以下程序創(chuàng)建了一個 String對象、ReferenceQueue對象和WeakReference對象： //創(chuàng)建一個強引用 String str = new String("hello"; //創(chuàng)建引用隊列, <String>為范型標(biāo)記，表明隊列中存放String對象的引用 ReferenceQueue<String> rq = new ReferenceQueue<String>(); //創(chuàng)建一個弱引用，它引用"hello"對象，并且與rq引用隊列關(guān)聯(lián) //<String>為范型標(biāo)記，表明WeakReference會弱引用String對象 WeakReference<String> wf = new WeakReference<String>(str, rq); 以上程序代碼執(zhí)行完畢，內(nèi)存中引用與對象的關(guān)系如下圖所示。 在圖11-10中，帶實線的箭頭表示強引用，帶虛線的箭頭表示弱引用。從圖中可以看出，此時"hello"對象被str強引用，并且被一個WeakReference對象弱引用，因此"hello"對象不會被垃圾回收。 在以下程序代碼中，把引用"hello"對象的str變量置為null，然后再通過WeakReference弱引用的get()方法獲得"hello"對象的引用： String str = new String("hello"; //① ReferenceQueue<String> rq = new ReferenceQueue<String>(); //② WeakReference<String> wf = new WeakReference<String>(str, rq); //③ str=null; //④取消"hello"對象的強引用 String str1=wf.get(); //⑤假如"hello"對象沒有被回收，str1引用"hello"對象 //假如"hello"對象沒有被回收，rq.poll()返回null Reference<? extends String> ref=rq.poll(); //⑥      執(zhí)行完以上第④行后，內(nèi)存中引用與對象的關(guān)系如下圖所示，此時"hello"對象僅僅具有弱引用，因此它有可能被垃圾回收。假如它還沒有被垃圾回收，那么 接下來在第⑤行執(zhí)行wf.get()方法會返回 "hello"對象的引用，并且使得這個對象被str1強引用。再接下來在第⑥行執(zhí)行rq.poll() 方法會返回null，因為此時引用隊列中沒有任何引用。ReferenceQueue的poll()方法用于返回隊列中的引用，如果沒有則返回null。      在以下程序代碼中，執(zhí)行完第④行后，"hello"對象僅僅具有弱引用。接下來兩次調(diào)用System.gc()方法，催促垃圾回收器工作，從而提高 "hello"對象被回收的可能性。假如"hello"對象被回收，那么WeakReference對象的引用被加入到 ReferenceQueue 中，接下來wf.get()方法返回null，并且rq.poll()方法返回WeakReference對象的引用。下圖 顯示了執(zhí)行完第⑧行后內(nèi)存中 引用與對象的關(guān)系。 String str = new String("hello"; //① ReferenceQueue<String> rq = new ReferenceQueue<String>(); //② WeakReference<String> wf = new WeakReference<String>(str, rq); //③ str=null; //④ //兩次催促垃圾回收器工作，提高"hello"對象被回收的可能性 System.gc(); //⑤ System.gc(); //⑥ String str1=wf.get(); //⑦ 假如"hello"對象被回收，str1為null Reference<? extends String> ref=rq.poll(); //⑧ 在 以下例程11-15的References類中，依次創(chuàng)建了10個軟引用、10個弱引用和10個虛引用，它們各自引用一個Grocery對象。從程序運行 時的打印結(jié)果可以看出，虛引用形同虛設(shè)，它所引用的對象隨時可能被垃圾回收，具有弱引用的對象擁有稍微長的生命周期，當(dāng)垃圾回收器執(zhí)行回收操作時，有可能 被垃圾回收，具有軟引用的對象擁有較長的生命周期，但在Java虛擬機認(rèn)為內(nèi)存不足的情況下，也會被垃圾回收。 例程11-15 References.java import java.lang.ref.*; import java.util.*; class Grocery{ private static final int SIZE = 10000; //屬性d使得每個Grocery對象占用較多內(nèi)存，有80K左右 private double[] d = new double[SIZE]; private String id; public Grocery(String id) { this.id = id; } public String toString() { return id; } public void finalize() { System.out.println("Finalizing " + id); } } public class References { private static ReferenceQueue<Grocery> rq = new ReferenceQueue<Grocery>(); public static void checkQueue() { Reference<? extends Grocery> inq = rq.poll(); //從隊列中取出一個引用 if(inq != null) System.out.println("In queue: "+inq+" : "+inq.get()); } public static void main(String[] args) { final int size=10; //創(chuàng)建10個Grocery對象以及10個軟引用 Set<SoftReference<Grocery>> sa = new HashSet<SoftReference<Grocery>>(); for(int i = 0; i < size; i++) { SoftReference<Grocery> ref= new SoftReference<Grocery>(new Grocery("Soft " + i), rq); System.out.println("Just created: " +ref.get()); sa.add(ref); } System.gc(); checkQueue(); //創(chuàng)建10個Grocery對象以及10個弱引用 Set<WeakReference<Grocery>> wa = new HashSet<WeakReference<Grocery>>(); for(int i = 0; i < size; i++) { WeakReference<Grocery> ref= new WeakReference<Grocery>(new Grocery("Weak " + i), rq); System.out.println("Just created: " +ref.get()); wa.add(ref); } System.gc(); checkQueue(); //創(chuàng)建10個Grocery對象以及10個虛引用 Set<PhantomReference<Grocery>> pa = new HashSet<PhantomReference<Grocery>>(); for(int i = 0; i < size; i++) { PhantomReference<Grocery>ref = new PhantomReference<Grocery>(new Grocery("Phantom " + i), rq); System.out.println("Just created: " +ref.get()); pa.add(ref); } System.gc(); checkQueue(); } }      在Java集合中有一種特殊的Map類型：WeakHashMap，在這種Map中存放了鍵對象的弱引用，當(dāng)一個鍵對象被垃圾回收，那么相應(yīng)的值對象的引 用會從Map中刪除。WeakHashMap能夠節(jié)約存儲空間，可用來緩存那些非必須存在的數(shù)據(jù)。關(guān)于Map接口的一般用法，可參見本書第15章的 15.4節(jié)（Map）。     以下例程11-16的MapCache類的main()方法創(chuàng)建了一個WeakHashMap對象，它存放了一組Key對象的弱引用，此外main()方法還創(chuàng)建了一個數(shù)組對象，它存放了部分Key對象的強引用。 例程11-16 MapCache.java import java.util.*; import java.lang.ref.*; class Key { String id; public Key(String id) { this.id = id; } public String toString() { return id; } public int hashCode() { return id.hashCode(); } public boolean equals(Object r) { return (r instanceof Key) && id.equals(((Key)r).id); } public void finalize() { System.out.println("Finalizing Key "+ id); } } class Value { String id; public Value(String id) { this.id = id; } public String toString() { return id; } public void finalize() { System.out.println("Finalizing Value "+id); } } public class MapCache { public static void main(String[] args) throws Exception{ int size = 1000; // 或者從命令行獲得size的大小 if(args.length > 0)size = Integer.parseInt(args[0]); Key[] keys = new Key[size]; //存放鍵對象的強引用 WeakHashMap<Key,Value> whm = new WeakHashMap<Key,Value>(); for(int i = 0; i < size; i++) { Key k = new Key(Integer.toString(i)); Value v = new Value(Integer.toString(i)); if(i % 3 == 0) keys[i] = k; //使Key對象持有強引用 whm.put(k, v); //使Key對象持有弱引用 } //催促垃圾回收器工作 System.gc(); //把CPU讓給垃圾回收器線程 Thread.sleep(8000); } } 以上程序的部分打印結(jié)果如下： Finalizing Key 998 Finalizing Key 997 Finalizing Key 995 Finalizing Key 994 Finalizing Key 992 Finalizing Key 991 Finalizing Key 989 Finalizing Key 988 Finalizing Key 986 Finalizing Key 985 Finalizing Key 983     從打印結(jié)果可以看出，當(dāng)執(zhí)行System.gc()方法后，垃圾回收器只會回收那些僅僅持有弱引用的Key對象。id可以被3整數(shù)的Key對象持有強引用，因此不會被回收。 Java調(diào)試平臺    Java Platform Debugger Architecture (JPDA:Java平臺調(diào)試架構(gòu)) 由Java虛擬機后端和調(diào)試平臺前端組成，Java虛擬機提供了Java調(diào)試的功能，而調(diào)試平臺通過調(diào)試交互協(xié)議向 Java虛擬機請求服務(wù)以對在虛擬機中運行的程序進行調(diào)試（見下圖）。     JPDA 通過兩個接口和協(xié)議來完成如上的說明，分別是JVMTI（Java虛擬機工具接口）、JDWP（Java調(diào)試連線協(xié)議）和JDI（Java調(diào)試接口）。 JVMTI定義了虛擬機應(yīng)該提供的調(diào)試服務(wù)，包括調(diào)試信息（Information譬如棧信息）、調(diào)試行為（Action譬如客戶端設(shè)置一個斷點）和通知 （Notification譬如到達某個斷點時通知客戶端），該接口由虛擬機實現(xiàn)者提供實現(xiàn)，并結(jié)合在虛擬機中；JDWP定義調(diào)試服務(wù)和調(diào)試器之間的通 信，包括定義調(diào)試信息格式和調(diào)試請求機制；而JDI在語言的高層次上定義了調(diào)試者可以使用的調(diào)試接口以能方便地與遠程的調(diào)試服務(wù)進行交互，Java語言實 現(xiàn)，調(diào)試器實現(xiàn)者可直接使用該接口訪問虛擬機調(diào)試服務(wù)。      當(dāng)虛擬機的調(diào)試服務(wù)運行時，虛擬機作為調(diào)試的服務(wù)提供端，監(jiān)聽一個連接，而調(diào)試 器通過該連接與虛擬機進行交互。目前，Windows平臺的JVM提供了兩種方式的連接：共享內(nèi)存和 Socket連接，共享內(nèi)存的服務(wù)提供端和調(diào)試端只 能位于同一臺機，而Socket連接則支持不同異機調(diào)試，即遠程調(diào)試。 在前面的篇章中，利用JPDA構(gòu)建調(diào)試平臺([a] http://www.blogcn.com/u2/38/21/ayufox/blog/36956440.html  [/a])介紹了如何使用Eclipse構(gòu)建測試平臺，在本篇將詳細(xì)介紹Sun HotSpot虛擬機提供啟用詳細(xì)參數(shù)設(shè)置。     1．啟用調(diào)試服務(wù)     -Xdebug 啟用調(diào)試     -Xrunjdwp:<sub-options> 加載JVM的JPDA參考實現(xiàn)庫     2．Xrunjdwp子參數(shù)（sub-options）配置     Xrunjdwp子參數(shù)的配置格式如下     -Xrunjdwp:<name1>[=<value1>],<name2>[=<value2>]...     可以指定如下子參數(shù)     help  打印幫助信息并結(jié)束虛擬機運行     transport 連接方式，有dt_socket和dt_shmem兩種，分別是Socket和共享內(nèi)存     server 是否以服務(wù)器方式啟，默認(rèn)為n，即虛擬機作為調(diào)試客戶端，一般將其指為y值，同時指定address參數(shù)，則虛擬機會監(jiān)聽到該address的調(diào)試請求，如果不指定address，則虛擬機使用address的默認(rèn)值     address 連接地址，當(dāng)指定server=n時，虛擬機在該地址上啟動調(diào)試器，如果server=y，虛擬機監(jiān)聽該地址。如果使用socket連接，則address的默認(rèn)值是一個隨機端口     launch 與onthrow 和/或 onuncaught（見下）結(jié)合使用，當(dāng)某個特定事件發(fā)生時，啟動一個調(diào)試器進程進行實時調(diào)試       onthrow 當(dāng)某個特定的異常拋出時才加載jdwp包，也就是當(dāng)異常拋出時才啟動調(diào)試服務(wù)     onuncaught 默認(rèn)值為n，如果設(shè)為y，則當(dāng)運行異常(RuntimeException)拋出時才加載jdwp包，即才啟動調(diào)試服務(wù)     stdalloc 默認(rèn)的，jdwp實現(xiàn)隨機使用一個內(nèi)存分配器來分配內(nèi)存，如果指定值為y，則使用C運行庫內(nèi)存分配器分配內(nèi)存     suspend 是否掛起，默認(rèn)值為y，即主程序并不馬上運行直到有調(diào)試請求到達，一般指定為n     3.例：     -Xrunjdwp:transport=dt_socket,server=y,address=8000     在8000端口監(jiān)聽Socket連接，掛起VM并且不加載運行主函數(shù)直到調(diào)試請求到達     -Xrunjdwp:transport=dt_shmem,server=y,suspend=n     選擇一個可用的共享內(nèi)存（因為沒有指address）并監(jiān)聽該內(nèi)存連接，同時加載運行主函數(shù)     -Xrunjdwp:transport=dt_socket,address=myhost:8000     連接到myhost:8000提供的調(diào)試服務(wù)（server=n，以調(diào)試客戶端存在），掛起VM并且不加載運行主函數(shù)     -Xrunjdwp:transport=dt_shmem,address=mysharedmemory     通過共享內(nèi)存的方式連接到調(diào)試服務(wù)，掛起VM并且不加載運行主函數(shù)     -Xrunjdwp:transport=dt_socket,server=y,address=8000,onthrow=java.io.IOException,launch=/usr/local/bin/debugstub      等待java.io.IOException被拋出，然后掛起VM并監(jiān)聽8000端口連接，在接到調(diào)試請求后以命令/usr/local/bin/debugstub dt_socket myhost:8000執(zhí)行     -Xrunjdwp:transport=dt_shmem,server=y,onuncaught=y,launch=d:\bin\debugstub.exe      等待一個RuntimeException被拋出，然后掛起VM并監(jiān)聽一個可用的共享內(nèi)存，在接到調(diào)試請求后以命令d:\bin\ debugstub.exe dt_shmem <address>執(zhí)行,<address>是可用的共享內(nèi)存 參考:JDK參考文檔 ayufox 發(fā)表于 >2006-7-12 12:47:20 [全文] [評論] [引用] [推薦] [檔案] [推給好友] [收藏到網(wǎng)摘] Sun HotSpot VM 垃圾回收調(diào)優(yōu)    Java 虛擬機的一個強大之處在于其提供垃圾自動回收，對開發(fā)人員掩蓋了內(nèi)存分配和回收的細(xì)節(jié)，然而，在某些大型應(yīng)用中，當(dāng)垃圾回收（GC）本身成為瓶頸，我們將 不可避免需要深入了解虛擬機掩蓋之下的一些細(xì)節(jié)。本篇將對Sun公司提供的HotSpot虛擬機（下面簡稱HS VM）的垃圾回收調(diào)優(yōu)做一些簡單的介紹。     一、在開始了解HS VM之前，先了解一些垃圾回收的基礎(chǔ)理論。     1．垃圾檢測：      任何虛擬機的回收算法都包括兩個步驟：檢測垃圾和回收垃圾。當(dāng)一個對象被創(chuàng)建時，其是活動的對象，此時其是可用的，而在運行過程中，該對象的引用不再被使 用，這時該對象就成為垃圾，一般采用兩種方式來區(qū)別活動對象和垃圾對象：引用計數(shù)和跟蹤。當(dāng)一個對象被其它對象引用時，其引用計數(shù)加1，當(dāng)不再被其它對象 引用時，計數(shù)減1，當(dāng)其引用計數(shù)為0時，該對象就成為垃圾，引用計數(shù)的缺點是無法檢測循環(huán)引用和維護引用計數(shù)的代價，在現(xiàn)代虛擬機中一般不采用該方式。而 跟蹤指的是虛擬機追蹤從根對象出發(fā)的有向?qū)ο髨D，如果一個對象不能被追蹤到，則該對象為垃圾，采用追蹤算法的垃圾回收器也叫標(biāo)記并回收回收器。     2．避免堆碎片：      在進行垃圾回收之后，由于內(nèi)存分配時，垃圾對象和活動對象可能相鄰存在，則可能會在堆中出現(xiàn)堆碎片，采用標(biāo)記并回收回收器的虛擬機一般采用兩種方法來對付 堆碎片：壓縮和拷貝。壓縮回收是指當(dāng)進行垃圾回收之后，將剩下的活動對象推向堆的另一端，則當(dāng)垃圾回收完畢之后在另一端形成連續(xù)的堆?？截惢厥罩傅氖潜３? 兩個同樣大小的堆，在對一個隊進行垃圾回收過程中，對于檢測出來的活動對象拷貝到另一個堆并連續(xù)存放。參見下圖     3．分代回收      拷貝回收的一個缺點在于有些對象是長期存在的，但在回收過程中仍然必須將這些對象多次拷貝，分代回收指的是，對不同年齡（在內(nèi)存存在的時間的長短）將對象 放入不同的代堆中，并對不同的代堆采用不同的回收算法。事實上，大部分的對象屬于“短命”對象，我們可以更多地對年輕的代堆進行垃圾回收，而對于年老的代 堆則減少回收頻度。     二、接下來我們介紹HS VM的一些垃圾回收調(diào)優(yōu)。     1．順序垃圾回收器     JDK5.0 的VM支持四種垃圾回收器，默認(rèn)的，HS VM采用順序垃圾回收器，順序垃圾回收器是一種single-threaded, stop-the- world回收器，即單線程，非并行（運行時，阻塞其他操作）的回收器。當(dāng)虛擬機初始化時，一個JVM所需的最大的內(nèi)存區(qū)地址空間被保留，但并沒有馬上分 配內(nèi)存而是需要時才分配（見下Virtual）。內(nèi)存空間分為三個區(qū)域：年輕代區(qū)(Young)、年老代區(qū)(Tenured)和永久區(qū)(Perm)。其分 布見下圖           年輕區(qū)分為三個區(qū)，一個Eden區(qū)和兩個Survivor區(qū)（拷貝回收），當(dāng)對象創(chuàng)建時，放入Eden區(qū)，而總有一個Survivor區(qū)是空的，隨著每一 次的垃圾回收，從Eden區(qū)和非空Survivor區(qū)的存活對象放入空survior區(qū)，當(dāng)一個對象經(jīng)過多次回收仍然存在，則將其轉(zhuǎn)入年老區(qū)。而永久區(qū)用 于保存一些永久對象，譬如一個類的描述和方法，常量等等。     以下是一些設(shè)置參數(shù)例子（下面例子的值都是Solaris Operating Environment SPARC Platform Edition使用的默認(rèn)值）：     堆空間設(shè)置：     -XX:MinHeapFreeRatio=40     -XX:MaxHeapFreeRatio=70     -Xms3670k     -Xmx64m      第一個表示當(dāng)空閑空間在代空間中比例低于40%時，將調(diào)整代空間將以使得空閑空間達到或者超過40%；第二個表示當(dāng)空閑空間在代空間中比例高于70%時， 將調(diào)整代空間以使得空閑空間不超過70%；第三個表示虛擬機初始化時將至少分配3670K內(nèi)存空間；第四個表示虛擬機最大使用的內(nèi)存空間不超過64M。 HSVM的建議是：一般來說，對于大型應(yīng)用，-Xmx64m是比較小的，應(yīng)根據(jù)內(nèi)存情況將其調(diào)整到盡量大的一個值。      代空間設(shè)置：     -XX:NewRatio=2     -XX:NewSize=2228k     -XX:MaxNewSize=unlimited(默認(rèn)是不限制的，如果需設(shè)置，在該處填相應(yīng)的值)     -XX:SurvivorRatio=32      第一個表示Young空間和Tenured空間的比例是1比2；第二個和第三個分別表示Young空間的最小和最大的邊界；第四個表示Eden和 Surivor空間的比例，譬如32，則表示Survivor空間占Young空間的1/34，當(dāng)Survivor空間太小時，當(dāng)Survivor空間填 滿，則將剩余的部分填到Tenured空間，而當(dāng)Survivor空間太大，則可能導(dǎo)致空閑空間太多，浪費內(nèi)存，可能通過-XX:+ PrintTenuringDistribution輸出Young空間的對象在各個區(qū)的情況。HSVM的建議是：盡量給Young空間足夠多的空間，除 非你認(rèn)為花在收集Tenured的時間過多，然而當(dāng)Young空間超過堆空間的一半時，結(jié)果可能會適得其反，當(dāng)增加處理器時，相應(yīng)地增加Young空間的 大小，因為內(nèi)存的分配可以并行進行。     2．其他垃圾回收器     HS VM其他的垃圾回收器包括：吞吐量回收器、并行回收器和漸進回收器（火車算法）。      吞吐量回收器對Young空間采用并行回收的策略，而Tenured空間則采用與順序回收器相同的策略，特點是吞吐量大（吞吐量是（工作時間—垃圾回收時 間）/工作時間），使用-XX:+UseParallelGC參數(shù)啟用吞 吐量回收器，當(dāng)系統(tǒng)擁有多個處理器時可使用該參數(shù)，并可通過指定參數(shù)-XX: ParallelGCThreads=<desired number>來設(shè)置回收線程數(shù)。         并行回收器對 Tenured空間采用并行回收的方式，特點是因回收垃圾而暫停的時間較小，使用-XX:+UseConcMarkSweepGC參數(shù)起用并行回收器，如 果與-XX:+UseParNewGC相結(jié)合，則Young空間也采用并行回收的方式，當(dāng)你可以從垃圾回收時間較小中得到好處時，可使用該參數(shù)，譬如人機 交互用戶對反應(yīng)時間比較敏感時可使用。     漸進回收器對Tenured空間采用漸進回收方式，即每一次回收并不對整個空間進行垃圾回收，而只 回收一部分，同樣的，其特點是回收垃圾而暫停的時間較小，然而，如果考慮到總的吞吐量，其回收速度比較Tenured空間默認(rèn)回收器還慢，使用- Xincgc參數(shù)啟用漸進回收器，當(dāng)系統(tǒng)負(fù)載不重可以經(jīng)常做垃圾回收時，使用該參數(shù)比較合適。     無論如何，系統(tǒng)調(diào)優(yōu)都是一件艱難的工作，如上列出來的只是一個簡單的介紹和一些常用的配置，而具體的情況則需要在系統(tǒng)開發(fā)中根據(jù)相應(yīng)的情況再做相應(yīng)的調(diào)整，以獲得令人滿意的系統(tǒng)的性能 參考：《深入Java虛擬機》 http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html 2006-7-7 JVM啟動參數(shù)         虛擬機服務(wù)器模式/客戶機模式，使用server模式可以提高性能，啟動比client模式慢，長期運行則比client模式快。當(dāng)該參數(shù)不指定時，虛擬 機啟動檢測主機是否為服務(wù)器，如果是則以server模式啟動，否則以client模式啟動，J2SE5.0檢測的根據(jù)是至少2個CPU和最低2GB內(nèi)存     2.-agentlib:<lib-name>=<options>       -agentpath:<lib-path>=<options>        本地類庫加載，當(dāng)你的部分類包含一些本地方法時，需要自己編寫本地代碼并位于操作系統(tǒng)加載共享包(dll)的路徑上，如果你不喜歡將該包放在操作系統(tǒng)識別 的加載上，則可以通過指定這個參數(shù)來加載自己的本地共享包(dll)。不同之處在于-agentlib中僅指定包名，根據(jù)操作系統(tǒng)的不同虛擬機在一定路徑 上搜索該包，譬如對于windows平臺虛擬機在PATH路徑上搜索該包，而lib-path則是指定全路徑，例如      -agentlib:hprof  在windows平臺虛擬機會在啟動時到PATH路徑上搜索hprof.dll并加載      虛擬機在加載代理包之后有一個啟動的操作（詳細(xì)參見JDK參考），<options>指的是代理包的啟動參數(shù)      3.-classpath classpath        -c classpath      指定類路徑，系統(tǒng)應(yīng)用類加載器(ClassLoader)會到該路徑下加載類      4.-Dproperty=value      設(shè)置系統(tǒng)屬性，可以通過System.getProperty(property)獲得      5.-enableassertions[:<package name>"..." | :<class name> ]        -ea[:<package name>"..." | :<class name> ]        -disableassertions[:<package name>"..." | :<class ; ]        -da[:<package name>"..." | :<class name> ]          啟用和停用斷言，默認(rèn)是停用斷言。斷言指的是從JDK1.4開始在支持的關(guān)鍵字assert，assert(booleanvalue)，當(dāng) booleanvalue為false時，拋出java.lang.AssertionError，必須指出的是，代碼編譯必須是1.4及其以上順從的， 即編譯時使用如下參數(shù)        java -source 1.4        一般僅在開發(fā)階段啟用斷言，而在運行階段不使用        其使用包括如下幾種情況        java -ea    //啟動斷言        java -eakname...  //在包pkname及其子包下起用斷言        java -eakname.classname  //對類 pkname.classname啟用斷言        停用斷言與啟用設(shè)置類似      6.-enablesystemassertions        -esa         -disablesystemassertions        -dsa         啟用和停用系統(tǒng)類斷言      7.-jar        運行包含在一個jar包里的程序，一般在jar包的/META-INF/MANIFEST.MF文件中指定Main-Class值為要運行的主函數(shù)，譬如                 Main-Class:ayufox.ejb3.Test      8.-javaagent:<classname>[<=options>]        加載java語言代理，該功能是JDK5新增加的，可以通過該設(shè)置在JVM運行主函數(shù)(main)之前做一些預(yù)處理工作，其中classname中必須包含有靜態(tài)方法        public static void premain(String agentArgs, Instrumentation inst) { ... }        上面的options即是傳入該函數(shù)的代理參數(shù)agentArgs，關(guān)于Instrumentation詳細(xì)參見包java.lang.instrument      9.-verbose        -verbose:class        -verbose:gc        -verbose:jni         在運行時        class:將類加載情況在控制臺中打印出來        gc:將虛擬機的垃圾回收事件信息打印        jni:放本地方法調(diào)用信息打印        -verbose與-verbose:class一樣      10.-version         -showversion         顯示版本信息，不同在于第一種顯示版本后虛擬機結(jié)束退出      11.-?         -help         顯示幫助信息并退出       12.-X         顯示非標(biāo)準(zhǔn)參數(shù)（見下面介紹）并退出      二、非標(biāo)準(zhǔn)參數(shù)（以-X開頭）      1.-Xint         所有字節(jié)碼以解析模式運行。第一代虛擬機即是以這種方式運行，由于需要Java解析器解析運行，所以效率比較低；第二代虛擬機則采用將字節(jié)碼編譯成本地代 碼的方式，效率大大提高；第三代虛擬機也叫自適應(yīng)(HotSpot)虛擬機，通過監(jiān)測代碼的執(zhí)行情況檢測出代碼被頻繁執(zhí)行的部分，將其盡量優(yōu)化成本地代碼 方式運行，而對于普通部分，則采用解析的模式運行。      2.-Xbatch        禁止后臺編譯，一般HotSpot虛擬機在檢測到一段代碼為頻繁執(zhí)行代碼需要將其編譯成本地代碼時，會啟動一個后臺線程完成這個工作，而同時采用解析的方式繼續(xù)運行字節(jié)碼。如果設(shè)置了該參數(shù)，則會停止繼續(xù)執(zhí)行字節(jié)碼，先將其編譯成本地代碼，然后再繼續(xù)執(zhí)行。      3.-Xdebug               -Xnoagent        -Xrun        -Xrunjdwp      啟用調(diào)試模式，見前面的《利用JPDA構(gòu)建調(diào)試平臺》這篇文章，后面將在一個獨立的文章中詳細(xì)介紹      4.-Xbootclasspath:bootclasspath          -Xbootclasspath/aath          -Xbootclasspath/path          設(shè)置啟動根Classpath，即使啟動類加載器將在何處加載對象，關(guān)于類啟動加載器，參見《JVM類加載器體系結(jié)構(gòu)》說明，分號后面的值指定路徑，以分 號隔開。其區(qū)別在于，-Xbootclasspath:bootclasspath將新的根加載路徑覆蓋默認(rèn)的路徑（\jre\lib\rt.jar）， -Xbootclasspath/aath將新的根加載路徑和原有的根加載路徑相結(jié)合，-Xbootclaspath/path將新的根加載路徑與原有的根加載路徑相結(jié)合，加載類時優(yōu)先搜索該加載路徑      5.-Xcheck:jni        對本地調(diào)用（JNI）采用更嚴(yán)格的檢測方式，在進行JNI調(diào)用之前檢測數(shù)據(jù)和傳入?yún)?shù)，如果碰到不合法的數(shù)據(jù)則強制結(jié)束掉虛擬機，對運行性能有損害      6.-Xfuture        對類格式(class文件格式)采用更嚴(yán)格的檢測方式，以便向后兼容，最好在開發(fā)時采用該參數(shù)      7.-Xnoclassgc        不使用垃圾回收      8.-Xloggc:file        與-verbose:gc功能一樣，不同在于-Xloggc:file將信息記錄到一個文件，而-verbose:gc將其輸出到控制臺      9.-Xincgc        -Xmsn        -Xmxn        -Xssn         跟內(nèi)存分配和垃圾回收相關(guān)，-Xincgc表示采用漸進式垃圾回收，-Xmsn設(shè)置初始內(nèi)存池大小，-Xmxn表示內(nèi)存池允許的最大大小，-Xssn是線程棧大小，n是要設(shè)置的值，必須是1024的倍數(shù)，譬如       -Xms6291456 -Xmx83886080       -Xms6144k -Xmx81920k       -Xms6m -Xmx80m       該部分對虛擬機的性能非常重要，在后面將有獨立的篇章詳細(xì)介紹      10.-Xprof         -Xrunhprof[:help][:<suboption>=<value>,...]       在運行時剖析運行情況，并將剖析結(jié)果打印到控制臺，其中后一個可以指定特定剖析對象，譬如cpu，堆(heap)等，可以運行java -Xrunhprof:help獲得可以剖析的對象和取值       11.-Xrs       減少JVM對操作系統(tǒng)信號量的使用，J2SE1.3.1開始引入。       SUN 在J2SE1.3.0中增加了Java應(yīng)用程序關(guān)閉時的回調(diào)鉤子(Hook)，以便當(dāng)JVM意外終止時用戶可以做一些資源清除工作。JVM監(jiān)視控制臺事件 以實現(xiàn)JVM意外終止時的回調(diào)。JVM明確地注冊了一個控制臺控制處理器，當(dāng)JVM接收到CTRL_C_EVENT,  CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, 或CTRL_SHUTDOWN事件時，該處理器介入關(guān)閉回掉鉤子 (HOOK)的處理。       如果虛擬機以服務(wù)的方式運行（譬如WEB服務(wù)器）當(dāng)其收到CTRL_LOGOFF_EVENT事件，由于系統(tǒng)并 不會因此終止JVM進程，故JVM不可以進行終止的操作，然而這與如上產(chǎn)生了沖突（不結(jié)束卻又調(diào)用關(guān)閉回調(diào)鉤子），為了避免這個問題，從 J2SE1.3.1使用-Xrs以使JVM不再監(jiān)測控制臺事件。