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

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

　　JRuby：一個(gè)純Java實(shí)現(xiàn)的Ruby解釋器。通過(guò)JRuby，你可以在JVM上直接運(yùn)行Ruby程序，調(diào)用Java的類庫(kù)。很多Java編寫(xiě)的Ruby IDE都是使用JRuby來(lái)解釋語(yǔ)法的。

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

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

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

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è)可變字符串用來(lái)構(gòu)建方法名稱

　　Method setMethod = null;

　　Method getMethod = null;

　　PropertyDescriptor pd = null;

　　try {

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

　　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()); //清空整個(gè)可變字符串

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

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

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

　　//構(gòu)建一個(gè)屬性描述器 把對(duì)應(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();//獲取對(duì)象的類型

　　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();//獲取對(duì)象的類型

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

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

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

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

　　那么，何謂可見(jiàn)性?多個(gè)線程之間是不能互相傳遞數(shù)據(jù)通信的，它們之間的溝通只能通過(guò)共享變量來(lái)進(jìn)行。Java內(nèi)存模型(JMM)規(guī)定了jvm有主內(nèi)存，主內(nèi)存是多個(gè)線程共享的。當(dāng)new一個(gè)對(duì)象的時(shí)候，也是被分配在主內(nèi)存中，每個(gè)線程都有自己的工作內(nèi)存，工作內(nèi)存存儲(chǔ)了主存的某些對(duì)象的副本，當(dāng)然線程的工作內(nèi)存大小是有限制的。當(dāng)線程操作某個(gè)對(duì)象時(shí)，執(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ī)范定義了線程對(duì)主存的操作指令：read，load，use，assign，store，write.當(dāng)一個(gè)共享變量在多個(gè)線程的工作內(nèi)存中都有副本時(shí)，如果一個(gè)線程修改了這個(gè)共享變量，那么其他線程應(yīng)該能夠看到這個(gè)被修改后的值，這就是多線程的可見(jiàn)性問(wèn)題。

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

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

　　Java代碼

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

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

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

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

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

　　那么顯然，最終的x的值是不可靠的。假設(shè)x現(xiàn)在為10，線程a加1，線程b減1，從表面上看，似乎最終x還是為10，但是多線程情況下會(huì)有這種情況發(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是一個(gè)銀行賬戶，線程a存款，線程b扣款，顯然這樣是有嚴(yán)重問(wèn)題的，要解決這個(gè)問(wèn)題，必須保證線程a和線程b是有序執(zhí)行的，并且每個(gè)線程執(zhí)行的加1或減1是一個(gè)原子操作。看看下面代碼：

　　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é)果都是不確定的，因?yàn)榫€程的執(zhí)行順序是不可預(yù)見(jiàn)的。這是java同步產(chǎn)生的根源，synchronized關(guān)鍵字保證了多個(gè)線程對(duì)于同步塊是互斥的，synchronized作為一種同步手段，解決java多線程的執(zhí)行有序性和內(nèi)存可見(jiàn)性，而volatile關(guān)鍵字之解決多線程的內(nèi)存可見(jiàn)性問(wèn)題。后面將會(huì)詳細(xì)介紹。

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

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

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

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

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

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

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

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

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

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

　　2.Framework的合理選用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　4，注重各個(gè)階段的工作

　　測(cè)試工作往往是很多項(xiàng)目經(jīng)理忽視，不愿意去花費(fèi)時(shí)間、費(fèi)用的內(nèi)容，因?yàn)槟菢訒?huì)增加項(xiàng)目的成本。但是，他們忽視了，項(xiàng)目的完成質(zhì)量往往對(duì)項(xiàng)目的成本有很大的關(guān)系。比如，如果軟件質(zhì)量很差，并沒(méi)有經(jīng)歷測(cè)試階段，其后期部署、運(yùn)行所帶來(lái)的費(fèi)用會(huì)遠(yuǎn)遠(yuǎn)超過(guò)前期的費(fèi)用。

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

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

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

引言

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

　　垃圾收集的意義

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

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

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

　　垃圾收集的算法分析

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

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

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

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

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

　　2、tracing算法(Tracing Collector)

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

　　3、compacting算法(Compacting Collector)

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

　　4、copying算法(Coping Collector)

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

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

　　5、generation算法(Generational Collector)

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

　　6、adaptive算法(Adaptive Collector)

　　在特定的情況下，一些垃圾收集算法會(huì)優(yōu)于其它算法。基于Adaptive算法的垃圾收集器就是監(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)行填寫(xiě)

　　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過(guò)去才能匹配

　java代碼：

　　class Person

　　public Person

　　}

　　class Student extends Person

　　public Student

　　public Student

　　}

　　class Test

　　}

　　/

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

　　輸出如下：

　　E：“JavaWorkjava Test

　　st1：

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

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

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

　　st2：

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

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

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

　　st3：

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

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

　　說(shuō)明了創(chuàng)建一個(gè)子類的對(duì)象實(shí)例的時(shí)候，必先調(diào)用父類的無(wú)參數(shù)的構(gòu)造函數(shù)(默認(rèn)構(gòu)造函數(shù))，假如父類有帶參數(shù)的構(gòu)造函數(shù)，那么系統(tǒng)將不會(huì)給它創(chuàng)建無(wú)參數(shù)的構(gòu)造函數(shù)，這時(shí)，子類在實(shí)例化的時(shí)候，因?yàn)檎也坏礁割惖哪J(rèn)構(gòu)造函數(shù)，編譯器將會(huì)報(bào)錯(cuò)，但假如在子類的構(gòu)造函數(shù)中指定用父類的帶參數(shù)的構(gòu)造函數(shù)的時(shí)候，或者在父類中加一個(gè)無(wú)參數(shù)的構(gòu)造函數(shù)，就不會(huì)報(bào)錯(cuò)。

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

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

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

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

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

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

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

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

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

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

　　(1)別用new Boolean()。

　　首先我們來(lái)看一下Java內(nèi)存管理第一個(gè)技巧，在很多場(chǎng)景中Boolean類型是必須的，比如JDBC中boolean類型的set與get都是通過(guò)Boolean封裝傳遞的，大部分ORM也是用Boolean來(lái)封裝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í)例的個(gè)數(shù)是相當(dāng)多的，所以系統(tǒng)中充滿了大量Boolean實(shí)例小對(duì)象，這是相當(dāng)消耗內(nèi)存的。Boolean類實(shí)際上只要兩個(gè)實(shí)例就夠了，一個(gè)true的實(shí)例，一個(gè)false的實(shí)例。

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

　　以下是引用片段：

　　以下是代碼片段：

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

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

　　因?yàn)関alueOf的內(nèi)部實(shí)現(xiàn)是：return (b ? TRUE : FALSE);

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

　　(2)別用new Integer。

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

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

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

(4)過(guò)濫使用哈希表

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

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

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

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

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

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

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