還記得以前本站的一篇文章《如何在Google App Engine上運行PHP》嗎，其實那是借用 Quercus，一個 100% 的用Java 實現(xiàn)的一個 PHP 引擎。今天，這樣的東西太多了，能運行在Java的虛擬機(jī)JVM上的程序意味著有天然的跨平臺性，現(xiàn)在JVM并不單單只能運行Java程序，在JVM上出現(xiàn)了若干使用Java虛擬機(jī)運行的腳本程序，比如什么PHP, Python, Ruby等等，這里有一篇文章評論了在JVM上的可以運行的排名前五腳本語言。他們分別是：

　　Groovy：構(gòu)建在強大的Java語言之上 并添加了從Python，Ruby和Smalltalk等語言中學(xué)到的諸多特征，為Java開發(fā)者提供了現(xiàn)代最流行的編程語言特性，而且學(xué)習(xí)成本很低(幾乎為零)，在開發(fā)Web，GUI，數(shù)據(jù)庫或控制臺程序時， 通過減少框架性代碼 大大提高了開發(fā)者的效率。支持單元測試和模擬(對象)，可以簡化測試。無縫集成 所有已經(jīng)存在的 Java對象和類庫。直接編譯成Java字節(jié)碼，這樣可以在任何使用Java的地方 使用Groovy。

　　JRuby：一個純Java實現(xiàn)的Ruby解釋器。通過JRuby，你可以在JVM上直接運行Ruby程序，調(diào)用Java的類庫。很多Java編寫的Ruby IDE都是使用JRuby來解釋語法的。

　　Scala：一種多范式的編程語言，設(shè)計意圖是要整合面向?qū)ο缶幊毯秃瘮?shù)式編程的各種特性。Scala編程語言近來抓住了很多開發(fā)者的眼球。它看起來像是一種純粹的面向?qū)ο缶幊陶Z言，而又無縫地結(jié)合了命令式和函數(shù)式的編程風(fēng)格。Scala的名稱表明，它還是一種高度可伸縮的語言。Scala的設(shè)計始終貫穿著一個理念：創(chuàng)造一種更好地支持組件的語言。

　　Fantom：Fantom 前身是 (Fan) 是一個基于 Java 和 .NET 平臺的編程腳本引擎，用來在運行時產(chǎn)生 JVM 和 .NET 平臺的字節(jié)碼，該語言是面向?qū)ο蟮?，?Groovy 和 JRuby 有點類似，可通過特定的接口來集成 Java 的類庫。

　　Jython：Jython由于繼承了Java和Python二者的特性而顯得很獨特。其是一種完整的語言，而不是一個Java翻譯器或僅僅是一個Python編譯器，它是一個Python語言在Java中的完全實現(xiàn)。Jython 也有很多從CPython中繼承的模塊庫。最有趣的事情是Jython不像CPython或其他任何高級語言，它提供了對其實現(xiàn)語言的一切存取。所以 Jython不僅給你提供了Python的庫，同時也提供了所有的Java類。這使其有一個巨大的資源庫。

import Java（Java教程 Java培訓(xùn) ）.lang.reflect.Method;

　　import java.lang.reflect.Field;

　　import java.beans.PropertyDescriptor;

　　public class PropertyUtil {

　　public static PropertyDescriptor getPropertyDescriptor(Class clazz， String propertyName) {

　　StringBuffer sb = new StringBuffer(); //構(gòu)建一個可變字符串用來構(gòu)建方法名稱

　　Method setMethod = null;

　　Method getMethod = null;

　　PropertyDescriptor pd = null;

　　try {

　　Field f = clazz.getDeclaredField(propertyName); //根據(jù)字段名來獲取字段

　　if (f != null) {

　　//構(gòu)建方法的后綴

　　String methodEnd = propertyName.substring(0， 1)。toUpperCase() + propertyName.substring(1);

　　sb.append(“set” + methodEnd); //構(gòu)建set方法

　　setMethod = clazz.getDeclaredMethod(sb.toString()， new Class[]{ f.getType() });

　　sb.delete(0， sb.length()); //清空整個可變字符串

　　sb.append(“get” + methodEnd); //構(gòu)建get方法

　　//構(gòu)建get 方法

　　getMethod = clazz.getDeclaredMethod(sb.toString()， new Class[]{ });

　　//構(gòu)建一個屬性描述器 把對應(yīng)屬性 propertyName 的 get 和 set 方法保存到屬性描述器中

　　pd = new PropertyDescriptor(propertyName， getMethod， setMethod);

　　}

　　} catch (Exception ex) {

　　ex.printStackTrace();

　　}

　　return pd;

　　}

　　public static void setProperty(Object obj，String propertyName，Object value){

　　Class clazz = obj.getClass();//獲取對象的類型

　　PropertyDescriptor pd = getPropertyDescriptor(clazz，propertyName);//獲取 clazz 類型中的 propertyName 的屬性描述器

　　Method setMethod = pd.getWriteMethod();//從屬性描述器中獲取 set 方法

　　try {

　　setMethod.invoke(obj， new Object[]{value});//調(diào)用 set 方法將傳入的value值保存屬性中去

　　} catch (Exception e){

　　e.printStackTrace();

　　}

　　}

　　public static Object getProperty(Object obj， String propertyName){

　　Class clazz = obj.getClass();//獲取對象的類型

　　PropertyDescriptor pd = getPropertyDescriptor(clazz，propertyName);//獲取 clazz 類型中的 propertyName 的屬性描述器

　　Method getMethod = pd.getReadMethod();//從屬性描述器中獲取 get 方法

　　Object value =null ;

　　try {

　　value = getMethod.invoke(clazz， new Object[]{});//調(diào)用方法獲取方法的返回值

　　} catch (Exception e) {

　　e.printStackTrace();

　　}

　　return value;//返回值

　　}

　　}

     摘要: Flex與Java中的Object進(jìn)行交互，需要準(zhǔn)備三個內(nèi)容，一個是Flex主文件，也就是我們的mxml文件，兩個Java 類，一個remoting-config.xml。為了減少程序的復(fù)雜性，這里只證明Flex可以調(diào)用Java中Object進(jìn)行交互，不進(jìn)行與數(shù)據(jù)庫的交互。 　　新建一個Java實體類：SpeakUser.java, 如下： 　　package com.cx.model; 　...  閱讀全文

最近想將Java（Java教程 Java培訓(xùn) ）基礎(chǔ)的一些東西都整理整理，寫下來，這是對知識的總結(jié)，也是一種樂趣。已經(jīng)擬好了提綱，大概分為這幾個主題： java線程安全，java垃圾收集，java并發(fā)包詳細(xì)介紹，java profile和jvm性能調(diào)優(yōu)。慢慢寫吧。本人jameswxx原創(chuàng)文章，轉(zhuǎn)載請注明出處，我費了很多心血，多謝了。關(guān)于java線程安全，網(wǎng)上有很多資料，我只想從自己的角度總結(jié)對這方面的考慮，有時候?qū)憱|西是很痛苦的，知道一些東西，但想用文字說清楚，卻不是那么容易。我認(rèn)為要認(rèn)識java線程安全，必須了解兩個主要的點：java的內(nèi)存模型，java的線程同步機(jī)制。特別是內(nèi)存模型，java的線程同步機(jī)制很大程度上都是基于內(nèi)存模型而設(shè)定的。后面我還會寫java并發(fā)包的文章，詳細(xì)總結(jié)如何利用java并發(fā)包編寫高效安全的多線程并發(fā)程序。暫時寫得比較倉促，后面會慢慢補充完善。

　　淺談java內(nèi)存模型

　　不同的平臺，內(nèi)存模型是不一樣的，但是jvm的內(nèi)存模型規(guī)范是統(tǒng)一的。其實java的多線程并發(fā)問題最終都會反映在java的內(nèi)存模型上，所謂線程安全無非是要控制多個線程對某個資源的有序訪問或修改?？偨Y(jié)java的內(nèi)存模型，要解決兩個主要的問題：可見性和有序性。我們都知道計算機(jī)有高速緩存的存在，處理器并不是每次處理數(shù)據(jù)都是取內(nèi)存的。JVM定義了自己的內(nèi)存模型，屏蔽了底層平臺內(nèi)存管理細(xì)節(jié)，對于java開發(fā)人員，要清楚在jvm內(nèi)存模型的基礎(chǔ)上，如果解決多線程的可見性和有序性。

　　那么，何謂可見性?多個線程之間是不能互相傳遞數(shù)據(jù)通信的，它們之間的溝通只能通過共享變量來進(jìn)行。Java內(nèi)存模型(JMM)規(guī)定了jvm有主內(nèi)存，主內(nèi)存是多個線程共享的。當(dāng)new一個對象的時候，也是被分配在主內(nèi)存中，每個線程都有自己的工作內(nèi)存，工作內(nèi)存存儲了主存的某些對象的副本，當(dāng)然線程的工作內(nèi)存大小是有限制的。當(dāng)線程操作某個對象時，執(zhí)行順序如下：

　　(1)從主存復(fù)制變量到當(dāng)前工作內(nèi)存(read and load)

　　(2)執(zhí)行代碼，改變共享變量值(use and assign)

　　(3)用工作內(nèi)存數(shù)據(jù)刷新主存相關(guān)內(nèi)容(store and write)

　　JVM規(guī)范定義了線程對主存的操作指令：read，load，use，assign，store，write.當(dāng)一個共享變量在多個線程的工作內(nèi)存中都有副本時，如果一個線程修改了這個共享變量，那么其他線程應(yīng)該能夠看到這個被修改后的值，這就是多線程的可見性問題。

　　那么，什么是有序性呢?線程在引用變量時不能直接從主內(nèi)存中引用，如果線程工作內(nèi)存中沒有該變量，則會從主內(nèi)存中拷貝一個副本到工作內(nèi)存中，這個過程為read-load，完成后線程會引用該副本。當(dāng)同一線程再度引用該字段時，有可能重新從主存中獲取變量副本(read-load-use)，也有可能直接引用原來的副本(use)，也就是說 read，load，use順序可以由JVM實現(xiàn)系統(tǒng)決定。

　　線程不能直接為主存中中字段賦值，它會將值指定給工作內(nèi)存中的變量副本(assign)，完成后這個變量副本會同步到主存儲區(qū)(store-write)，至于何時同步過去，根據(jù)JVM實現(xiàn)系統(tǒng)決定。有該字段，則會從主內(nèi)存中將該字段賦值到工作內(nèi)存中，這個過程為read-load，完成后線程會引用該變量副本，當(dāng)同一線程多次重復(fù)對字段賦值時，比如：

　　Java代碼

　　for(int i=0;i<10;i++)

　　a++;線程有可能只對工作內(nèi)存中的副本進(jìn)行賦值，只到最后一次賦值后才同步到主存儲區(qū)，所以assign，store，weite順序可以由JVM實現(xiàn)系統(tǒng)決定。假設(shè)有一個共享變量x，線程a執(zhí)行x=x+1.從上面的描述中可以知道x=x+1并不是一個原子操作，它的執(zhí)行過程如下：

　　1、從主存中讀取變量x副本到工作內(nèi)存2、給x加1 3、將x加1后的值寫回主 存

　　如果另外一個線程b執(zhí)行x=x-1，執(zhí)行過程如下：

　　1、從主存中讀取變量x副本到工作內(nèi)存2、給x減1 3、將x減1后的值寫回主存

　　那么顯然，最終的x的值是不可靠的。假設(shè)x現(xiàn)在為10，線程a加1，線程b減1，從表面上看，似乎最終x還是為10，但是多線程情況下會有這種情況發(fā)生：

　　1：線程a從主存讀取x副本到工作內(nèi)存，工作內(nèi)存中x值為10 2：線程b從主存讀取x副本到工作內(nèi)存，工作內(nèi)存中x值為10 3：線程a將工作內(nèi)存中x加1，工作內(nèi)存中x值為11 4：線程a將x提交主存中，主存中x為11 5：線程b將工作內(nèi)存中x值減1，工作內(nèi)存中x值為9 6：線程b將x提交到中主存中，主存中x為9

　　同樣，x有可能為11，如果x是一個銀行賬戶，線程a存款，線程b扣款，顯然這樣是有嚴(yán)重問題的，要解決這個問題，必須保證線程a和線程b是有序執(zhí)行的，并且每個線程執(zhí)行的加1或減1是一個原子操作?？纯聪旅娲a：

　　Java代碼

　　public class Account {

　　private int balance;

　　public Account(int balance) { this.balance = balance;}

　　public int getBalance() { return balance;}

　　public void add(int num) { balance = balance + num;}

　　public void withdraw(int num) { balance = balance - num;}

　　public static void main(String[] args) throws InterruptedException { Account account = new Account(1000);Thread a = new Thread(new AddThread(account， 20)， "add");Thread b = new Thread(new WithdrawThread(account， 20)， "withdraw");a.start();b.start();a.join();b.join();System.out.println(account.getBalance());}

　　static class AddThread implements Runnable { Account account;int amount;

　　public AddThread(Account account， int amount) { this.account = account;this.amount = amount;}

　　public void run() { for (int i = 0; i < 200000; i++) { account.add(amount);}

　　static class WithdrawThread implements Runnable { Account account;int amount;

　　public WithdrawThread(Account account， int amount) { this.account = account;this.amount = amount;}

　　public void run() { for (int i = 0; i < 100000; i++) { account.withdraw(amount);}第一次執(zhí)行結(jié)果為10200，第二次執(zhí)行結(jié)果為1060，每次執(zhí)行的結(jié)果都是不確定的，因為線程的執(zhí)行順序是不可預(yù)見的。這是java同步產(chǎn)生的根源，synchronized關(guān)鍵字保證了多個線程對于同步塊是互斥的，synchronized作為一種同步手段，解決java多線程的執(zhí)行有序性和內(nèi)存可見性，而volatile關(guān)鍵字之解決多線程的內(nèi)存可見性問題。后面將會詳細(xì)介紹。

J2EE（J2EE培訓(xùn) ），作為開發(fā)mission-critical的企業(yè)級應(yīng)用的一整套規(guī)范的整合平臺，規(guī)范多、內(nèi)容廣，從而給開發(fā)J2EE應(yīng)用帶來了很多“麻煩”。比如，為實現(xiàn)內(nèi)容的RDBMS，我們可能的方法有JDBC、Entity Beans、JDO、O/R Mapping工具(TopLink、Hibernate)、XML-DBMS、JAXB等方法(其中一些方法不是J2EE規(guī)范所包含的)。

　　因此，為實現(xiàn)J2EE各層(至少有表示層、控制層、商業(yè)邏輯層等3層)以及層與層之間的耦合，J2EE系統(tǒng)架構(gòu)師需要考慮的問題會很多。加上，J2EE本身的快速發(fā)展，給架構(gòu)、開發(fā)具有工業(yè)強度的J2EE應(yīng)用帶來一些難題。

　　同時，軟件開發(fā)技術(shù)從來就沒有“銀彈”，所以J2EE技術(shù)也不是萬能的。但是，如果我們在結(jié)合具體商業(yè)需求的基礎(chǔ)上，合理的應(yīng)用好J2EE技術(shù)，其結(jié)果可想而知。本文試圖從本人以往的項目經(jīng)驗入手，來探討開發(fā)J2EE應(yīng)用時應(yīng)該遵循的幾點準(zhǔn)則，希望起到拋磚引玉的作用。本文結(jié)合JBoss 3.2.1下的J2EE應(yīng)用開發(fā)為例展開論述。

　　1.結(jié)合商業(yè)需求選擇合理的架構(gòu)

　　如果脫離商業(yè)需求，而單獨的討論技術(shù)本身的優(yōu)勢是不夠的。各項技術(shù)都有產(chǎn)生的特定背景，其中很多都是來自工業(yè)需求而觸動的。一般而言，企業(yè)信息系統(tǒng)(EIS)都要求自己穩(wěn)定、、可靠、高效、便于維護(hù)。同時，各個企業(yè)信息系統(tǒng)都有自己獨特的要求，可能有些時候需要考慮與原有遺留系統(tǒng)的集成，所以了解各個企業(yè)信息系統(tǒng)具體的商業(yè)需求對于整個系統(tǒng)的架構(gòu)顯得很關(guān)鍵。

　　比如，如果待開發(fā)的J2EE應(yīng)用系統(tǒng)中使用到的數(shù)據(jù)大部分來自于外在數(shù)據(jù)源;而這些數(shù)據(jù)可能是通過JDBC直接從外在數(shù)據(jù)源導(dǎo)入到待開發(fā)的J2EE系統(tǒng)的Database中。對于這種情形，如果在開發(fā)過程中，僅僅使用JDBC來操作數(shù)據(jù)庫，對于小強度(并發(fā)訪問用戶少、數(shù)據(jù)流量少)的情形，顯然是比較合適的;但如果，并發(fā)訪問用戶較多、數(shù)據(jù)流量大，對Database層使用較為頻繁的情形，則顯得有些力不從心。

　　因此，對于這種需求，我們可以考慮采用Entity Beans with Caches。打個比方，在JBoss 3.2.1中對于Entity Beans的Cache策略有多種，這時可以考慮使用，即“Standard CMP 2.x EntityBean”，方式并采用“D”類型的commit-option來保證Entity Beans的內(nèi)容與數(shù)據(jù)源的同步，并使得系統(tǒng)的性能得到大大改善(同直接使用JDBC相比)。其中，可以將一些Entity Beans設(shè)置為read-only，以改善性能。當(dāng)然，在這里也可以采用其他一些O/R Mapping技術(shù)，比如TopLink。

　　再比如，考慮這樣一種情形：如果待開發(fā)的企業(yè)信息系統(tǒng)使用到的數(shù)據(jù)都是由系統(tǒng)本身生成和操作的，則建議采用：CMP Entity Beans技術(shù)。Entity Beans給大家的印象很壞，這可能與EJB 1.1給大家留下的壞映象有關(guān)吧。但是，EJB 2.0(或者說2.1)得到了很大的改善，Local Interfaces、CMR、Read-Only、Session Fa?ade模式給Entity Beans注入了活力。當(dāng)然，并發(fā)用戶多、數(shù)據(jù)流量很大時才會體現(xiàn)出使用Entity Beans的優(yōu)勢。其中，有一點很關(guān)鍵：要注重Entity Beans技術(shù)的性能調(diào)優(yōu)，各個應(yīng)用都有自己的一套性能調(diào)優(yōu)方案。

　　對于JBoss 3.2.1，配置文件standardjboss.xml提供了Entity Beans技術(shù)調(diào)優(yōu)的入口。比如，Bean Lock策略的合理使用對于Entity Beans的調(diào)優(yōu)就顯得很重要。這樣使得，我們可以更加關(guān)注于系統(tǒng)的商業(yè)邏輯，而不只是底層的Database(EJB調(diào)優(yōu)處于EJB Container中，因此我們處在J2EE性能的高端，而不是底端，即Database層。同時，Database層的調(diào)優(yōu)使得J2EE系統(tǒng)的數(shù)據(jù)庫移植性大打折扣。)。

　　簡而言之，要結(jié)合各個系統(tǒng)的特定需求和狀況給出具體的技術(shù)架構(gòu)方案，而不能孤單的論述技術(shù)本身的好壞。

　　2.Framework的合理選用

　　設(shè)計模式在J2EE應(yīng)用系統(tǒng)中扮演著重要的角色。因此，有一個問題擺在大家面前，是自己來實現(xiàn)具體的設(shè)計模式，還是借助于Third-party Framework。如果貴公司不大，或者說公司不想在J2EE基礎(chǔ)應(yīng)用Framework投入很多精力，選用現(xiàn)有的較為成熟的、穩(wěn)定、與現(xiàn)有J2EE Specification兼容的技術(shù)框架會比較明智。

　　一般而言，F(xiàn)ramework本身，或者說J2EE平臺本身都是實現(xiàn)并優(yōu)化了具體的設(shè)計模式、規(guī)則，比如業(yè)務(wù)代理、Service Locator(包括Web Tier和EJB Tier各自的服務(wù)定位器，起到統(tǒng)一管理有限資源、Cache相關(guān)資源的作用，便于系統(tǒng)移植)、Front Controller、DAO等等。現(xiàn)有的J2EE Framework比較豐富。比如：

　　Struts: 對于實現(xiàn)了Model 2類型的Framework，對于現(xiàn)在以及將來(隨著JSF規(guī)范、技術(shù)的成熟)，選用她是一種明智之舉。目前，Struts已經(jīng)發(fā)展到1.1版本。其內(nèi)在的MVC主線、對后端數(shù)據(jù)操作方式?jīng)]有限定、集合了Apache Jakarta項目組的優(yōu)秀相關(guān)項目的精華，可謂是開發(fā)J2EE應(yīng)用的佳品。同時，對于具有.NET Web Forms功能的下一代J2EE平臺技術(shù)JSF而言，Struts本身可考慮到與JSF的兼容和集成性。比如，通過JSP呈現(xiàn)表示層、Servlet呈現(xiàn)控制層、EJB呈現(xiàn)數(shù)據(jù)層。各層之間，可以通過值對象、HTTP相關(guān)對象來通訊，實現(xiàn)J2EE相關(guān)技術(shù)的完美應(yīng)用。

　　Log4j: 我想對于習(xí)慣采用“System.out.println(“”);”的讀者而言，Log4j是大家的福音。盡管 2 Standard Edition也具備java.util.logging包來保證日志的輸出，但Log4j的簡單、高效、靈活已經(jīng)成了很多項目的選擇。日志，在某種程度上可以考驗系統(tǒng)的穩(wěn)定性、正確性，所以采用可配置的Log4j(目前，Log4j已經(jīng)考慮到了與java.util.logging包的兼容性)是不會錯的。比如，JBoss 3.2.1本身就是借助于Log4j來管理日志的。

　　realMethods: 可能有些讀者還不知道這一款殺手锏。那好，這里就簡要作一介紹。realMethods是一開發(fā)J2EE應(yīng)用的Framework，她不同于Struts(主要在于實現(xiàn)Model 2，J2EE應(yīng)用前端);realMethods對于J2EE應(yīng)用的各個層面都有詳盡、高效的支持。同時，realMethods以前還是商用軟件，現(xiàn)在已經(jīng)成為了Open Source的產(chǎn)品，因此現(xiàn)在可以參看其全部源代碼。

　　BC4J: 公司推出的用于的商業(yè)組件。其內(nèi)容和外在的特點和優(yōu)勢，不言而喻。

　　當(dāng)然，類似的Framework很多很多。作為開發(fā)J2EE應(yīng)用的團(tuán)隊而言，我們需要對各種Framework加以篩選，選擇適合項目需求、團(tuán)隊、公司發(fā)展方向的框架。

　　一般情況下，待開發(fā)的目標(biāo)產(chǎn)品不宜采用過多的Framework。

　　其一，J2EE各個技術(shù)發(fā)展很快，過多的Framework使得系統(tǒng)的后續(xù)升級、維護(hù)不利;

　　其二，可以借鑒其中的好的一面，比如研究realMethods實現(xiàn)的相應(yīng)的設(shè)計模式，并改造她以適合我們的項目需求;

　　其三，F(xiàn)ramework本身會有變動，如果選用過多，會給開發(fā)團(tuán)隊加重負(fù)擔(dān)，從而不利于項目管理。有選擇的使用現(xiàn)有的成熟Framework能提升大家的開發(fā)效率、開發(fā)水平。

　　3，開發(fā)模式的選擇

　　開發(fā)J2EE應(yīng)用要求目標(biāo)開發(fā)人員能夠掌握其中的各種技術(shù)。但是，現(xiàn)實情況不是這樣。作為一個團(tuán)隊，每個人都有自己不同的技能優(yōu)勢、興趣以及悟性。同時，J2EE本身需要體現(xiàn)社會分工。一般情況下，我們的開發(fā)團(tuán)隊不會有Specification所要求的各個開發(fā)角色?，F(xiàn)實往往只有3種(也可能是兩種)：美工、JSP程序員、EJB程序員。面對這種分工，團(tuán)隊更要注重溝通、交流，注重代碼的一致性。

　　一般情況下，團(tuán)隊要盡量采用版本控制工具管理代碼、盡量做到每天都有一個完整的運行版本。經(jīng)過一段時間，團(tuán)隊都會適應(yīng)這種開發(fā)模式。其中，版本控制工具一定要使用，便于代碼的管理、控制和備份。這其中會牽扯到很多層面。比如，開發(fā)工具的選擇要考慮到版本控制工具的使用、建模工具的合理使用有助于團(tuán)隊有效的溝通和交流。

　　基于現(xiàn)有的開發(fā)模式，個人認(rèn)為這樣3套方案不錯。第一，采用Together作為建模工具、采用JBuilder作為IDE工具、采用VSS(或者CVS)作為版本控制工具、采用JBoss作為開發(fā)J2EE應(yīng)用開發(fā)階段的。第二，采用WebSphere Studio整套工具。第三，采用Eclipse(或者JCreator)、Ant、XDoclets作為開發(fā)工具。

　　當(dāng)然，手工完成J2EE應(yīng)用的編寫、編譯、打包、部署、更能使開發(fā)者理解各個開發(fā)階段的具體細(xì)節(jié)。但本人認(rèn)為，只要開發(fā)者有這種關(guān)注具體細(xì)節(jié)的態(tài)度，選用功能強大的建模、開發(fā)工具是明智的。開發(fā)工具不能提高開發(fā)人員的開發(fā)技能，但是她能夠引導(dǎo)開發(fā)人員正確的開發(fā)方向。比如,JBuidler 9 Enterprise提供的EJB精靈具有的“Struts + EJB + Session Fa?ade + Value Object”等功能呈現(xiàn)了業(yè)界廣泛應(yīng)用的J2EE構(gòu)架方式。

　　4，注重各個階段的工作

　　測試工作往往是很多項目經(jīng)理忽視，不愿意去花費時間、費用的內(nèi)容，因為那樣會增加項目的成本。但是，他們忽視了，項目的完成質(zhì)量往往對項目的成本有很大的關(guān)系。比如，如果軟件質(zhì)量很差，并沒有經(jīng)歷測試階段，其后期部署、運行所帶來的費用會遠(yuǎn)遠(yuǎn)超過前期的費用。

　　測試是分階段的。單元測試，比如借助于JUnit，來保證功能正確等內(nèi)容。集成測試，來保證系統(tǒng)沒有內(nèi)存泄漏等內(nèi)容。其中，Optimizeite Suite Enterprise對于完成Profiler、Code Coverage、Thread Debugger等內(nèi)容很有幫助。我記得，我寫的一個Swing桌面應(yīng)用存在內(nèi)容泄漏，但是想了很多辦法都沒有解決問題。后來，采用Profiler獲得了答案。因此，現(xiàn)在開發(fā)應(yīng)用，我們很多時候都采用Optimizeite Suite Enterprise作為測試工具。尤其是，在做集成測試過程中，檢查系統(tǒng)的內(nèi)存泄漏、性能很有幫助。

　　測試是分類型的。壓力測試、性能測試。就目前對支持J2EE應(yīng)用的測試而言，并沒有很好的測試工具。但是，一般情況下，借助于Rational Robot也能夠取得不錯的效果。

　　當(dāng)然，成功開發(fā)J2EE應(yīng)用的因素有很多。比如，Entity Beans的成功應(yīng)用很大程度上與底層Database的設(shè)計有關(guān)系(如果表結(jié)構(gòu)設(shè)計設(shè)計的不合理，將導(dǎo)致Entity Beans性能的急劇下降);如何最大化挖掘、提升團(tuán)隊各個成員的J2EE技能。等等這些，設(shè)計面很廣。希望對你有幫助。

引言

　　Java的堆是一個運行時數(shù)據(jù)區(qū)，類的實例(對象)從中分配空間。Java虛擬機(jī)(JVM)的堆中儲存著正在運行的應(yīng)用程序所建立的所有對象，這些對象通過new、newarray、anewarray和multianewarray等指令建立，但是它們不需要程序代碼來顯式地釋放。一般來說，堆的是由垃圾回收來負(fù)責(zé)的，盡管JVM規(guī)范并不要求特殊的垃圾回收技術(shù)，甚至根本就不需要垃圾回收，但是由于內(nèi)存的有限性，JVM在實現(xiàn)的時候都有一個由垃圾回收所管理的堆。垃圾回收是一種動態(tài)存儲管理技術(shù)，它自動地釋放不再被程序引用的對象，按照特定的垃圾收集算法來實現(xiàn)資源自動回收的功能。

　　垃圾收集的意義

　　在C++中，對象所占的內(nèi)存在程序結(jié)束運行之前一直被占用，在明確釋放之前不能分配給其它對象;而在Java中，當(dāng)沒有對象引用指向原先分配給某個對象的內(nèi)存時，該內(nèi)存便成為垃圾。JVM的一個系統(tǒng)級線程會自動釋放該內(nèi)存塊。垃圾收集意味著程序不再需要的對象是“無用信息”，這些信息將被丟棄。當(dāng)一個對象不再被引用的時候，內(nèi)存回收它占領(lǐng)的空間，以便空間被后來的新對象使用。事實上，除了釋放沒用的對象，垃圾收集也可以清除內(nèi)存記錄碎片。由于創(chuàng)建對象和垃圾收集器釋放丟棄對象所占的內(nèi)存空間，內(nèi)存會出現(xiàn)碎片。碎片是分配給對象的內(nèi)存塊之間的空閑內(nèi)存洞。碎片整理將所占用的堆內(nèi)存移到堆的一端，JVM將整理出的內(nèi)存分配給新的對象。

　　垃圾收集能自動釋放內(nèi)存空間，減輕編程的負(fù)擔(dān)。這使Java 虛擬機(jī)具有一些優(yōu)點。首先，它能使編程效率提高。在沒有垃圾收集機(jī)制的時候，可能要花許多時間來解決一個難懂的存儲器問題。在用Java語言編程的時候，靠垃圾收集機(jī)制可大大縮短時間。其次是它保護(hù)程序的完整性， 垃圾收集是Java語言安全性策略的一個重要部份。

　　垃圾收集的一個潛在的缺點是它的開銷影響程序性能。Java虛擬機(jī)必須追蹤運行程序中有用的對象，而且最終釋放沒用的對象。這一個過程需要花費處理器的時間。其次垃圾收集算法的不完備性，早先采用的某些垃圾收集算法就不能保證100%收集到所有的廢棄內(nèi)存。當(dāng)然隨著垃圾收集算法的不斷改進(jìn)以及軟硬件運行效率的不斷提升，這些問題都可以迎刃而解。

　　垃圾收集的算法分析

　　Java語言規(guī)范沒有明確地說明JVM使用哪種垃圾回收算法，但是任何一種垃圾收集算法一般要做2件基本的事情：(1)發(fā)現(xiàn)無用信息對象;(2)回收被無用對象占用的內(nèi)存空間，使該空間可被程序再次使用。

　　大多數(shù)垃圾回收算法使用了根集(root set)這個概念;所謂根集就量正在執(zhí)行的Java程序可以訪問的引用變量的集合(包括局部變量、參數(shù)、類變量)，程序可以使用引用變量訪問對象的屬性和調(diào)用對象的方法。垃圾收集首選需要確定從根開始哪些是可達(dá)的和哪些是不可達(dá)的，從根集可達(dá)的對象都是活動對象，它們不能作為垃圾被回收，這也包括從根集間接可達(dá)的對象。而根集通過任意路徑不可達(dá)的對象符合垃圾收集的條件，應(yīng)該被回收。下面介紹幾個常用的算法。

　　1、 引用計數(shù)法(Reference Counting Collector)

　　引用計數(shù)法是唯一沒有使用根集的垃圾回收的法，該算法使用引用計數(shù)器來區(qū)分存活對象和不再使用的對象。一般來說，堆中的每個對象對應(yīng)一個引用計數(shù)器。當(dāng)每一次創(chuàng)建一個對象并賦給一個變量時，引用計數(shù)器置為1。當(dāng)對象被賦給任意變量時，引用計數(shù)器每次加1當(dāng)對象出了作用域后(該對象丟棄不再使用)，引用計數(shù)器減1，一旦引用計數(shù)器為0，對象就滿足了垃圾收集的條件。

　　基于引用計數(shù)器的垃圾收集器運行較快，不會長時間中斷程序執(zhí)行，適宜地必須 實時運行的程序。但引用計數(shù)器增加了程序執(zhí)行的開銷，因為每次對象賦給新的變量，計數(shù)器加1，而每次現(xiàn)有對象出了作用域生，計數(shù)器減1。

　　2、tracing算法(Tracing Collector)

　　tracing算法是為了解決引用計數(shù)法的問題而提出，它使用了根集的概念?；趖racing算法的垃圾收集器從根集開始掃描，識別出哪些對象可達(dá)，哪些對象不可達(dá)，并用某種方式標(biāo)記可達(dá)對象，例如對每個可達(dá)對象設(shè)置一個或多個位。在掃描識別過程中，基于tracing算法的垃圾收集也稱為標(biāo)記和清除(mark-and-sweep)垃圾收集器。

　　3、compacting算法(Compacting Collector)

　　為了解決堆碎片問題，基于tracing的垃圾回收吸收了Compacting算法的思想，在清除的過程中，算法將所有的對象移到堆的一端，堆的另一端就變成了一個相鄰的空閑內(nèi)存區(qū)，收集器會對它移動的所有對象的所有引用進(jìn)行更新，使得這些引用在新的位置能識別原來的對象。在基于Compacting算法的收集器的實現(xiàn)中，一般增加句柄和句柄表。

　　4、copying算法(Coping Collector)

　　該算法的提出是為了克服句柄的開銷和解決堆碎片的垃圾回收。它開始時把堆分成 一個對象 面和多個空閑面，程序從對象面為對象分配空間，當(dāng)對象滿了，基于coping算法的垃圾 收集就從根集中掃描活動對象，并將每個活動對象復(fù)制到空閑面(使得活動對象所占的內(nèi)存之間沒有空閑洞)，這樣空閑面變成了對象面，原來的對象面變成了空閑面，程序會在新的對象面中分配內(nèi)存。

　　一種典型的基于coping算法的垃圾回收是stop-and-copy算法，它將堆分成對象面和空閑區(qū)域面，在對象面與空閑區(qū)域面的切換過程中，程序暫停執(zhí)行。

　　5、generation算法(Generational Collector)

　　stop-and-copy垃圾收集器的一個缺陷是收集器必須復(fù)制所有的活動對象，這增加了程序等待時間，這是coping算法低效的原因。在程序設(shè)計中有這樣的規(guī)律：多數(shù)對象存在的時間比較短，少數(shù)的存在時間比較長。因此，generation算法將堆分成兩個或多個，每個子堆作為對象的一代 (generation)。由于多數(shù)對象存在的時間比較短，隨著程序丟棄不使用的對象，垃圾收集器將從最年輕的子堆中收集這些對象。在分代式的垃圾收集器運行后，上次運行存活下來的對象移到下一最高代的子堆中，由于老一代的子堆不會經(jīng)常被回收，因而節(jié)省了時間。

　　6、adaptive算法(Adaptive Collector)

　　在特定的情況下，一些垃圾收集算法會優(yōu)于其它算法?；贏daptive算法的垃圾收集器就是監(jiān)控當(dāng)前堆的使用情況，并將選擇適當(dāng)算法的垃圾收集器。

java代碼：

　　/**

　　* 刪除cookie

　　*/

　　public static void clearCookie(HttpServletRequest request，HttpServletResponse response， String path) {

　　Cookie[] cookies = request.getCookies();

　　try{

　　for(int i=0;i《cookies.length;i++) {

　　//System.out.println(cookies[i].getName() + ”：” + cookies[i].getValue());

　　Cookie cookie = new Cookie(cookies[i].getName()， null);

　　cookie.setMaxAge(0);

　　cookie.setPath(path);//根據(jù)你創(chuàng)建cookie的路徑進(jìn)行填寫

　　response.addCookie(cookie);

　　}

　　}catch(Exception ex) {

　　System.out.println(“刪除Cookies發(fā)生異常!”);

　　}

　　}

　　public static void setCookie(HttpServletResponse response， String name， String value， String path) {

　　if (logger.isDebugEnabled()) {

　　logger.debug(“Setting cookie ’” + name + “‘ on path ’” + path + “‘”);

　　}

　　Cookie cookie = new Cookie(name， value);

　　cookie.setSecure(false);

　　cookie.setPath(path);

　　cookie.setMaxAge(Constants.COOKIE_INVALID_TIME);

　　response.addCookie(cookie);

　　// logger.info(”setCookie 完成……。”);

　　}

　　//調(diào)用

　　String cookiename = “vbo”;

　　String cookievalue = “cb”;

　　String path = “/”;

　　setCookie(response， cookiename ， cookievalue ， path);

　　clearCookie(request，response，path);//如果有name的話，方法也要增加name過去才能匹配

　java代碼：

　　class Person

　　public Person

　　}

　　class Student extends Person

　　public Student

　　public Student

　　}

　　class Test

　　}

　　/

　　=======================================

　　輸出如下：

　　E：“JavaWorkjava Test

　　st1：

　　person無參數(shù)構(gòu)造函數(shù)

　　student 無參數(shù)的構(gòu)造函數(shù)

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

　　st2：

　　person無參數(shù)構(gòu)造函數(shù)

　　student 3 參數(shù)的構(gòu)造函數(shù)

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

　　st3：

　　person 2 參數(shù)的構(gòu)造函數(shù)

　　student 4 參數(shù)的構(gòu)造函數(shù)，super.

　　說明了創(chuàng)建一個子類的對象實例的時候，必先調(diào)用父類的無參數(shù)的構(gòu)造函數(shù)(默認(rèn)構(gòu)造函數(shù))，假如父類有帶參數(shù)的構(gòu)造函數(shù)，那么系統(tǒng)將不會給它創(chuàng)建無參數(shù)的構(gòu)造函數(shù)，這時，子類在實例化的時候，因為找不到父類的默認(rèn)構(gòu)造函數(shù)，編譯器將會報錯，但假如在子類的構(gòu)造函數(shù)中指定用父類的帶參數(shù)的構(gòu)造函數(shù)的時候，或者在父類中加一個無參數(shù)的構(gòu)造函數(shù)，就不會報錯。

　　=============================================

　　我們假設(shè)A是B的父類，B是A的子類。

　　1、假如程序員沒有給類A沒有提供構(gòu)造函數(shù)，則編譯器會自動提供一個默認(rèn)的無參數(shù)的構(gòu)造函數(shù)，假如用戶提供了自己的構(gòu)造函數(shù)，則編譯器就不在提供默認(rèn)的無參數(shù)構(gòu)造函數(shù)。

　　2、子類B實例化時會自動調(diào)用父類A的默認(rèn)構(gòu)造函數(shù)，所以假如A的默認(rèn)的無參數(shù)的構(gòu)造函數(shù)為private，則編譯器會報錯，而假如A沒有提供默認(rèn)的無參數(shù)的構(gòu)造函數(shù)，而提供了其他類型的構(gòu)造函數(shù)，編譯器同樣會報錯，因為B找不到A的默認(rèn)無參數(shù)構(gòu)造函數(shù)。所以，我們最好給父類A提供一個無參數(shù)的構(gòu)造函數(shù)。

　　3、或者在B的構(gòu)造函數(shù)中顯示的調(diào)用父類A的有參構(gòu)造函數(shù)。

你對Java內(nèi)存管理技巧是否了解，這里和大家分享一下，Java做的系統(tǒng)給人的印象是什么?占內(nèi)存!說道這句話就會有N多人站出來為java辯護(hù)，并舉出一堆的性能測試報告來證明這一點。

　　遠(yuǎn)離陋習(xí)Java內(nèi)存管理的9個小技巧

　　從理論上來講java做的系統(tǒng)并不比其他語言開發(fā)出來的系統(tǒng)更占用內(nèi)存，那么為什么卻有這么N多理由來證明它確實占內(nèi)存呢?兩個字，陋習(xí)。本文將介紹幾則Java內(nèi)存管理的小技巧，讓你告別陋習(xí)，為自己所編寫的Java程序提速。

　　Java做的系統(tǒng)給人的印象是什么?占內(nèi)存!說道這句話就會有N多人站出來為java辯護(hù)，并舉出一堆的性能測試報告來證明這一點。

　　其實從理論上來講java做的系統(tǒng)并不比其他語言開發(fā)出來的系統(tǒng)更占用內(nèi)存，那么為什么卻有這么N多理由來證明它確實占內(nèi)存呢?兩個字，陋習(xí)。

　　(1)別用new Boolean()。

　　首先我們來看一下Java內(nèi)存管理第一個技巧，在很多場景中Boolean類型是必須的，比如JDBC中boolean類型的set與get都是通過Boolean封裝傳遞的，大部分ORM也是用Boolean來封裝boolean類型的，比如：

　　以下是引用片段：

　　以下是代碼片段：

　　ps.setBoolean("isClosed",new Boolean(true));

　　ps.setBoolean("isClosed",new Boolean(isClosed));

　　ps.setBoolean("isClosed",new Boolean(i==3));

　　通常這些系統(tǒng)中構(gòu)造的Boolean實例的個數(shù)是相當(dāng)多的，所以系統(tǒng)中充滿了大量Boolean實例小對象，這是相當(dāng)消耗內(nèi)存的。Boolean類實際上只要兩個實例就夠了，一個true的實例，一個false的實例。

　　Boolean類提供兩了個靜態(tài)變量：

　　以下是引用片段：

　　以下是代碼片段：

　　public static final Boolean TRUE = new Boolean(true);

　　public static final Boolean FALSE = new Boolean(false);

　　因為valueOf的內(nèi)部實現(xiàn)是：return (b ? TRUE : FALSE);

　　所以可以節(jié)省大量內(nèi)存。相信如果Java規(guī)范直接把Boolean的構(gòu)造函數(shù)規(guī)定成private，就再也不會出現(xiàn)這種情況了，下面再來看一下Java內(nèi)存管理的第二個技巧。

　　(2)別用new Integer。

　　和Boolean類似，java開發(fā)中使用Integer封裝int的場合也非常 多，并且通常用int表示的數(shù)值通常都非常小。SUN SDK中對Integer的實例化進(jìn)行了優(yōu)化,Integer類緩存了-128到127這256個狀態(tài)的Integer，如果使用 Integer.valueOf(int i)，傳入的int范圍正好在此內(nèi)，就返回靜態(tài)實例。這樣如果我們使用Integer.valueOf代替new Integer的話也將大大降低內(nèi)存的占用。如果您的系統(tǒng)要在不同的SDK(比如IBM SDK)中使用的話，那么可以自己做了工具類封裝一下，比如IntegerUtils.valueOf(),這樣就可以在任何SDK中都可以使用這種特性。

　　(3)用StringBuffer代替字符串相加。

　　這個我就不多講了，因為已經(jīng)被 人講過N次了。我只想將一個不是笑話的笑話，我在看國內(nèi)某“著名”java開發(fā)的WEB系統(tǒng)的源碼中，竟然發(fā)現(xiàn)其中大量的使用字符串相加，一個拼裝SQL 語句的方法中竟然最多構(gòu)造了將近100個string實例。無語中!

(4)過濫使用哈希表

　　有一定開發(fā)經(jīng)驗的開發(fā)人員經(jīng)常會使用hash表(hash 表在JDK中的一個實現(xiàn)就是HashMap)來緩存一些數(shù)據(jù)，從而提高系統(tǒng)的運行速度。比如使用HashMap緩存一些物料信息、人員信息等基礎(chǔ)資料，這 在提高系統(tǒng)速度的同時也加大了系統(tǒng)的內(nèi)存占用，特別是當(dāng)緩存的資料比較多的時候。其實我們可以使用操作系統(tǒng)中的緩存的概念來解決這個問題，也就是給被緩存 的分配一個一定大小的緩存容器，按照一定的算法淘汰不需要繼續(xù)緩存的對象，這樣一方面會因為進(jìn)行了對象緩存而提高了系統(tǒng)的運行效率，同時由于緩存容器不是無限制擴(kuò)大，從而也減少了系統(tǒng)的內(nèi)存占用?，F(xiàn)在有很多開源的緩存實現(xiàn)項目，比如ehcache、oscache等，這些項目都實現(xiàn)了FIFO、MRU等常見的緩存算法。

　　(5)避免過深的類層次結(jié)構(gòu)和過深的方法調(diào)用。

　　另外在進(jìn)行Java內(nèi)存管理要注意避免過深的類層次結(jié)構(gòu)和過深的方法調(diào)用，因為這兩者都是非常占用內(nèi)存的(特別是方法調(diào)用更是堆棧空間的消耗大戶)。

　　(6)變量只有在用到它的時候才定義和實例化。

　　(7)盡量避免使用static變量，類內(nèi)私有常量可以用final來代替。

　　(8)對頻繁使用的對象采用對象池技術(shù)

　　(9)保證每個IO操作，connection及時關(guān)閉