機器兩臺：
A機器：172.16.48.26：用于Alfresco服務器（集群節點1）
用于數據庫服務器、文件服務器（共享）、
B機器：172.16.48.27：用于Alfresco服務器（集群節點2）
負載均衡服務器
第一步：創建共用數據庫
在A機器：172.16.48.26 上安裝MySQL，建立名為alfresco的數據庫；
#create database alfresco
#grant all privileges on alfresco.* to root@'%' identified by 'alfresco'
第二步：創建共享目錄
在A機器：172.16.48.26上建立可寫的共享目錄 /alfresco；
在/下創建目錄 alfresco
#mkdir /alfresco
第三步：設置共享目錄
在A機器：172.16.48.26 上安裝Samba，修改/etc/samba/smb.conf，增加以下內容
security = user
[alfresco]
comment = alfresco data & log
path = /alfresco
public = yes
writable = yes
write list = @root
第四步：建立Samba用戶
在A機器：172.16.48.26建立Samba用戶root
#smbpasswd -a root
第五步：建立共享
在B機器：172.16.48.27上創建/alfresco目錄并掛載A機器的 共享目錄//172.16.48.26/alfresco
# mount -t smbfs -o username=root,password=alfresco //172.16.48.26/alfresco /alfresco
第六步：安裝tomcat并修改配置
A機器：172.16.48.26 上安裝tomcat，并修改conf/server.xml
maxThreads="20000"
emptySessionPath="true"
protocol="org.apache.coyote.http11.Http11NioProtocol"
enableLookups="false"
redirectPort="8443"
connectionTimeout="20000"
disableUploadTimeout="true" />
在B機器：172.16.48.27 上安裝tomcat，并修改conf/server.xml，內容同上，然后將jvmRoute改為tomcat2；
第七步：部署alfersco
將alfresco.war分別拷貝到A機器：172.16.48.26和B機器：172.16.48.27的webapps目錄下，并解壓縮到alfresco目錄
#jar -xf alfresco.war
第八步：修改alfresco配置
分別對兩臺機器的alfresco的配置做修改
1、修改WEB-INF/classes/alfresco/repository.properties文件
dir.root=./alfresco_data
db.name=alfresco
db.url=jdbc:mysql://172.16.48.26:3306/${db.name}
db.username=root
db.password=alfresco
2、拷貝extension目錄(在repository項目的config中)下的內容分別到172.16.48.26和172.16.48.27的WEB-INF/classes/alfresco/extension目錄下，
包括：
custom-hibernate-dialect.properties
custom-repository-context.xml
custom-repository.properties
ehcache-custom.xml
replicating-content-services-context.xml
以及自己定義的content的配置
3、修改custom-hibernate-dialect.properties文件
hibernate.dialect=org.hibernate.dialect.MySQLInnoDBDialect
4、修改custom-repository.properties文件
dir.root=./alfresco_data
index.recovery.mode=AUTO
index.tracking.cronExpression=0/5 * * * * ?
index.tracking.reindexLagMs=10000
db.driver=org.gjt.mm.mysql.Driver
db.name=alfresco
db.url=jdbc:mysql://172.16.48.26:3306/${db.name}
db.username=root
db.password=alfresco
5、修改ehcache-custom.xml文件
properties="port=40001, socketTimeoutMillis=300000"/>
6、修改replicating-content-services-context.xml文件
./alfresco_data/contentstore
/alfresco/contentstore
第九步：啟動tomcat
修改172.16.48.26的bin/catalina.sh文件，啟動tomcat
export JAVA_OPTS='-Xms512m -Xmx2048m -XX:MaxPermSize=512m -server'
#./bin/startup.sh
修改172.16.48.27的bin/catalina.sh文件，內容同上，啟動tomcat；
第十步：安裝文件服務器
在172.16.48.26上安裝apache httpd server到目錄/usr/local/apache目錄下，
拷貝從apache網站找到的 mod_jk.so到modules目錄下
修改conf/httpd.conf
LoadModule jk_module modules/mod_jk.so
JkWorkersFile conf/workers.properties
JkLogFile logs/mod_jk.log
JkLogLevel info
JkMount /* loadBalancer
JkMount /jkstatus status
Include conf/extra/httpd-mpm.conf
Include conf/extra/httpd-default.conf
添加文件conf/workers.properties
worker.list=tomcat1, tomcat2, loadBalancer, status
worker.tomcat1.port=8009
worker.tomcat1.host=172.16.48.26
worker.tomcat1.type=ajp13
worker.tomcat2.port=8009
worker.tomcat2.host=172.16.48.27
worker.tomcat2.type=ajp13
worker.loadBalancer.type=lb
worker.loadBalancer.balance_workers=tomcat1, tomcat2
worker.loadbalancer.sticky_session=true
worker.loadbalancer.sticky_session_force=false
worker.status.type=status
修改conf/extra/httpd-default.conf文件
Timeout 300
KeepAlive On
MaxKeepAliveRequests 0
KeepAliveTimeout 300
修改conf/extra/httpd-mpm.conf文件
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 4096
MaxClients 2048
MaxRequestsPerChild 0
ThreadsPerChild 1024
MaxRequestsPerChild 0
啟動apache httpd server
第十一步：測試
在A機器創建用戶test
使用test用戶創建文件 file1.txt
在B機器使用test用戶搜索 file1；
在B機器使用test用戶創建文件 file2.txt
在A機器使用test用戶搜索 file2；
原文鏈接：http://blog.csdn.net/wangxiaojing123/article/details/6682706
假設你是正在開發和維護一個包含2000個類并使用了很多框架的Java開發人員。你要如何理解這些代碼？在一個典型的Java企業項目小組中，大 部分能夠幫你的高級工程師看起來都很忙。文檔也很少。你需要盡快交付成果，并向項目組證明自己的能力。你會如何處理這種狀況？這篇文字為開始一個新項目的 Java開發者提供了一些建議。
0. 不要試圖一下子搞懂整個項目好好考慮一下，為什么理解項目代碼是第一位的？大部分情況是你被要求修復一個bug或者加強系統已有功能。你要做的第一件事情不是理解整個項目的架構。當對項目進行維護時，這樣（理解整個項目架構）可能會對你造成巨大的壓力。
即便是有著10年可靠編程經驗的Java開發者可能也沒有理解項目的核心工作機制，盡管他們可能已經在這個項目工作超過一年（假設他們并非原始開發人員）。比如，對于認證機制或事務管理機制。
他們是怎么做的？他們對于自己負責的部分非常了解，并且能夠交付價值給小組。每天的交付價值遠比了解一些以后還不確定有沒有的東西重要的多。
1. 關注于盡快交付價值
那我是否定了你對于項目架構理解的熱情了么？完全不。我只是要求你盡早的交付價值，一旦你開始一個項目，搭建了開發環境，你就不應該花一兩周時間才交付什么，無論他的規模大小。假如你是一個有經驗的程序員卻兩周都沒有任何交付，你的經理怎么會知道你是真的在工作還是在看新聞。
所以交付可以使大家都輕松起來。不要認為你能夠做有價值的交付前必須理解整個項目。這是完全錯誤的。加一段javascript的驗證代碼對業務就很有價值，經理能夠通過你的交付達到對你的信任。這樣能夠向上級領導證明你的貢獻以及員工價值。
日復一日，在你不斷修復bug及增強功能之后，就能夠慢慢開始理解項目架構。不要低估對系統方方面面理解時需要花費的時間。花3-4天理解認證機 制，2-3天理解事物管理。這些都是依靠之前的相似項目的經歷，但關鍵還是要花時間才能透徹的理解。要在日常工作中擠出時間，不要向經理要求特定的時間來做這些。
找找項目是否有一些不斷維護的單元測試用例。有效的單元測試用例是理解大型項目代碼的很好途徑。單元測試能夠幫助理解代碼片段，包括一個單元的外部接口（單元如何被調用以及返回內容）及其內部實現（調試單元測試比調試整個實際用例簡單許多）。
你如果能夠很好的理解一些內容，寫一些筆記，或者畫一些類圖、時序圖、數據模型圖，以便你或日后其他的開發者維護。
2. 維護大型項目所必須的技能
你能從事當前的工作，必然已經具有良好的java技術。我們來談談能夠讓你在新項目中良好表現的其他技能。大部分時間，你在項目中的任務是修復bug和增強功能。
有兩項很重要的技能能夠協助你維護大型項目代碼。
2.1 能夠迅速發現需要的類
在任何維護活動中，無論是修復bug或增強功能，第一個動作就是識別出當前修復或增強的用例中調用的類。當你定位到需要修復或增強的類/方法，就已經完工了一半。
2.2 能夠分析變更的影響當你在完成必要的修改或增強工作后，最重要的就是要確認你的修改沒有破壞代碼的其他部分。你要用你的java技術及對其他框架的理解找出變更可能影響的部分。下面有兩個簡單的例子詳細描述了最后提及的情況：
a）當類A的equals()方法變更后，調用一個保護A實例的List的contains()方法時就會被影響到。若Java知識不夠，很難考慮到這樣的影響。
b）在一個web項目中，我們假設“user id”保存在session中。一個新入程序員可能在“user id”中加入一些信息作為bug修復的方法，但是卻不知道會影響到那些關聯“user id”的用例。
當你提高了如上兩個技能，盡管你對項目不是非常了解，但大部分的維護任務會變得簡單很多。若你修復一個bug，你會定位并修復這個bug，并且保證變更不會破壞項目的其他部分。若你增強或加入一個特性，基本上你只需要模仿現有的特性使用相似的設計。
在一個在線銀行項目中，為什么“查看賬戶摘要”和“查看交易歷史”的設計需要巨大的差別呢？如果你理解了“查看賬戶摘要”的設計，完全可以模仿開發出“查看交易歷史”的功能。
就修復bug和增強來說，你不必完全理解所有2000個類的工作內容和代碼如何運行來推動系統。你若有上面的技能，就能很快定位需要修改的代碼的部分，使用良好的java和框架技能修復，保證變更不會破壞項目的其他部分并交付，盡管你可能只知道一小部分項目的設計。
3. 使用工具找到需要的變更內容以及變更產生的影響繼續我們盡快交付的主題，你應當尋找那些能夠通過盡量少的了解項目但能幫助你盡快實施交付的工具作為輔助。
3.1 迅速發現需要變更內容的工具無論是修復bug還是系統增強，首先都要找到該用例調用的你需要修改的類及方法。基本有兩種方式理解一個用例的工作方式，靜態代碼分析和運行時分析。
源碼分析統計掃描所有代碼并且展示類之間的關系。市場上有很多設備與工具。比如：Architexa， AgileJ， UModel， Poseidon等。
所有的靜態代碼分析工具缺點在于無法確切展示用例中類或方法的運行時調用情況。因此Java新加入了特性，如回調機制（callback patterns）。如靜態分析工具無法推斷出當頁面提交按鈕被點擊時哪個Servlet被調用了。
運行時分析工具能夠展示類和方法在用例運行時的狀態。工具包括：MaintainJ， Diver，jSonde，Java Call Tracer等。這些工具可以捕獲運行時的堆棧狀態，并以此為一個用例生成序列圖和類圖。
序列圖展示了該用例在運行時所有調用的方法。若你在修復一個bug，那這個bug很可能就是這些被調用的方法之一。
若你在增強已有功能，利用序列圖理解調用流程然后再修改。可能是新增一個驗證，修改DAO等。
若你在新增功能，找到一些相似的特性，利用序列圖理解調用流程然后模仿開發新功能。
要小心挑選運行時分析工具。信息過多是這類工具的主要問題。選擇一些提供簡單過濾無效信息并能夠方便的查看各種視圖的工具。
3.2 迅速發現需要變更內容的工具若單元測試有效，可以通過運行單元測試發現變更有沒有破壞其他測試用例。有效維護并且覆蓋大型企業應用的單元測試還是比較少的。下面有一些針對該情況的工具。
仍然是有兩種技術靜態代碼分析和運行時分析可以使用。市場中有很多靜態代碼分析工具可用。如：Lattix, Structure101, Coverity, nWire and IntelliJ’s DSM。
給定一個變更后的類，上述工具均可識別對該類存在依賴的類的集合。開發者需要根據這些信息“猜測”可能產生影響的用例，因為這些工具無法展示運行時類之間的調用關系。
市場上的可以用于運行時影響分析的工具并不多，除了MaintainJ。MaintainJ先捕獲在一個用例中調用的所有類和方法。當所有用例的上 述信息都被捕獲之后，就很容易發現類的變更對用例的影響。MaintainJ能夠有效工作的前置條件就是項目的所有用例都應當先運行一遍，以便能夠獲得運 行時的依賴關系。
總之，目前你在迅速準確分析變更影響方面，還是可以從工具中獲得有限的幫助。首先根據需要實施一些影響分析，然后根據自己或小組其他高級成員評審來判斷變更的影響。你可能需要上面提到的工具對你的判斷進行反復確認。
4. 對上述內容的兩個忠告
4.1 不要降低代碼質量
為了快速交付，所以沒有全盤理解架構，但絕不能以降低代碼質量為條件。下面是一些你可能因為只考慮快速交付而引發的代碼質量問題。
因為修改代碼涉及到很多的依賴，所以新增代碼相對而言風險較小。例如，有5個用例都調用了某個方法。為了改進某個用例，你需要修改這個方法的實現。 最簡單的做法就是復制這個方法，重命名，然后在改進的用例中調用新方法。千萬不要這么做。代碼冗余絕對是非常有害的。嘗試對方法進行包裝或者重寫，甚至是 直接修改，然后重新測試所有用例，通常停下來想一想，然后親手去實施，是一個比較好的方式。
（ 伯樂在線配圖）
另一個例子是將“private”方法改為“public”，使得別的類也可以調用。盡量不要將非必須的部分暴露出來。假如為了更好的設計需要重構，就應當著手去做。
大部分應用都有確定的結構和模式來實施。修復或增強程序時，確認你沒有偏離這樣的模式。若對約定不確定，請其他的高級開發者來審核你的變更。若你必須做一些違背約定的實施，盡量放置于一個規模較小的類中（一個200行代碼的類中的私有函數應當不會影響應用的整體設計）
4.2 不要停止深入理解項目架構按照文章列出的方式，假設你能夠在對項目了解較少的情況下進行交付并以此持續下去，可能你會停止對項目架構的深入了解。這樣從長遠角度來說對你的職 業生涯沒有幫助。當你的經驗增加時，你應當承擔比較大的模塊任務。如構建一個完整的新特性或者修改項目的一些基礎設計等較大的改進。當你能夠做這些改進 時，你對項目的整體架構應該相當了解。文中列舉的方法是讓你在最短的時間內提升自己，而不是阻止你完整理解整個項目。
5. 結論整篇文章集中在對項目進行必要了解的前提下進行快速交付。你可以在不降低代碼質量的前提下這么做。
若修復一個bug，迅速定位并修復。有必要可以使用運行時分析工具。若新增一個特寫，可以尋找相似特寫，理解流程（有必要使用工具）并編寫。
或許這些聽起來很簡單，但是實用嗎？當然。但前提是你有良好的java技術以及對框架足夠了解才能先修改代碼，然后對變更影響進行分析。對變更影響的分析比實施變更需要更多的技巧。你可能需要高級開發人員協助你分析變更影響。
大約有50%的IT可操作預算用于簡單的bug修復和功能增強。根據文中的建議，對于維護活動中的經費的節省應當還是很有幫助的。
作者 Choudary Kothapalli 也是 MaintainJ 項目的建立者。
代碼編寫規范目的：能夠在編碼過程中實現規范化，為以后的程序開發中養成良好的行為習慣。
代碼編寫規范使用范圍：J2EE項目開發。
包命名規范：
目的：包的命名規范應當體現出項目資源良好的劃分
servlet類所在包命名規范：公司名稱.開發組名稱.項目名稱.web.servlet
例如：net.linkcn.web.servlet
自定義標簽類所在包命名規范：公司名稱.開發組名稱.項目名稱.web.tags
例如：net.linkcn.web.tags
過濾器類所在包命名規范：公司名稱.開發組名稱.項目名稱.web.filter
例如：net.linkcn.web.filter
Action類所在包命名規范：公司名稱.開發組名稱.項目名稱.web.struts.action
例如：net.linkcn.web.struts.action
ActionForm類所在包命名規范：公司名稱.開發組名稱.項目名稱.web.struts.form
例如：net.linkcn.web.struts.form
Javabean所在包命名規范：公司名稱.開發組名稱.項目名稱.web.struts.service.impl
例如：net.linkcn.web.service.impl
Javabean實現接口命名規范：公司名稱.開發組名稱.項目名稱.web.service
例如：net.linkcn.web.service
DAO類所在包命名規范：公司名稱.開發組名稱.項目名稱.dao.impl
例如：net.linkcn.dao.impl
DAO類所實現的接口在包中命名規范：公司名稱.開發組名稱.項目名稱.dao
例如：net.linkcn.dao
POJO類與hbm文件所在包命名規范：公司名稱.開發組名稱.項目名稱.dao.hbm
例如：net.linkcn.dao.hbm
全局公共類、接口類所在包命名規范：公司名稱.開發組名稱.項目名稱.global
例如：net.linkcn.global
全局工具類所在包命名規范：公司名稱.開發組名稱.項目名稱.util
例如：net.linkcn.util
類命名規范
基本命名規范：
類、接口命名
命名規范：以大寫字母開頭，如果有多個單詞，每個單詞頭字母大寫
例如：StudentInfo
接口命名
命名規范：以大寫字母"I"開頭，如果有多個單詞，每個單詞頭字母大寫
例如：IStudentInfo
接口實現類命名：
命名規范：將實現的接口名稱的首字母"I"去掉，以"Impl作為結尾"，如果有多個單詞，每個單詞頭字母大寫。
例如：StudentInfoImpl
J2EE+SSH框架命名規范
servlet類命名：
命名規范：以Servlet單詞結尾
例如：LoginServlet
POJO命名：
使用hibernate自動生成的類即可
DAO類命名：
使用hibernate自動生成的類即可
Action類命名：
命名規范：Action的命名以POJO名稱來制定，POJO名稱Action
例如：
一個POJO名稱為Diary，其對應的action為DiaryAction
ActionForm類命名：
命名規范：ActionForm的命名以POJO名稱來制定，POJO名稱Form
例如：
一個POJO名稱為Diary，其對應的actioForm為DiaryForm
業務邏輯接口命名:
命名規范：業務邏輯接口的命名以POJO名稱來制定，IPOJO名稱Service
例如：
一個POJO名稱為Diary，其對應的業務邏輯接口為IDiaryService
業務邏輯實現類命名:
命名規范：業務邏輯接口實現類的命名以POJO名稱來制定
例如：
一個POJO名稱為Diary，對應的業務邏輯接口實現類名為DiaryServiceImpl
類變量命名：
命名規范：變量名首字母必須小寫，如果該變量名有多個單詞組成，后面的單 詞首字母大寫，單詞與單詞之間不要使用"_"做連接，變量名訪問控制必須為私有， 可以對其增加setter與getter方法。
例如：
private int studentAge;
public int getStudentAge(){
return studentAge;
}
public void setStudentAge(int studentAge) {
this.studentAge=studentAge;
}
常量命名：
命名規范：所有字母大寫，如果有多個單詞組成，單詞與單詞之間以” _“隔開。而 且該變量必須是公共、靜態、final類型
例如：public static final String USER_NAME=”userName“;
方法命名
命名規范：首字母必須小寫，如果該變量名有多個單詞組成，后面的單詞首字母 大寫，單詞與單詞之間不要使用"_"做連接。單詞不要使用名詞。
例如：public int checkLogin（String name,String pwd）{}
注釋規范：注釋規范是整個開發規范中最為重要的組成部分，必須嚴格執行。
類的注釋：
作用：注釋整個類，簡單概述該類作用。
書寫規范：類的注釋必須寫在該類的聲明語法之前。在注釋中要描述該類的基 本作用，作者，日期，版本，公司名稱，版權聲明。
格式：
類的聲明語法
例如：
public class AdminDAO
變量、常量注釋：
作用：簡單描述該變量的意義。
書寫規范：變量注釋必須寫在變量定義之前，簡單描述其代表的意義。
格式：
例如：
public int age;
方法注釋：
作用：對該方法功能簡單描述，其參數、返回值意義的注解。
書寫規范：方法注釋必須寫在方法定義之前。該注釋包括：方法其功能的簡單 描述，方法的參數、返回值類型、返回值意義簡單的描述。
格式：
例如：
public booleaneditAdminPassword(int adminId,String oldPassword,
String password) throws UserException,ServiceException;
Jsp頁面命名：
命名規范：jsp頁面名稱要以小寫字母開頭，如果有多個單詞組成，后面的單詞以 大寫字母開頭。名稱要體現出該頁面的意義，最好能夠與模塊名稱聯系在一起。
例如：
login.jsp --登錄頁面
register.jsp --注冊頁面
message.jsp --客戶留言頁面
J2EE項目工程文件夾組織規范：
目的：規范學員web應用程序的資源組織形式，形成良好的文件組織習慣。文件的組織形式應當體現模塊的劃分。
根據eclipse工具的特征，項目的目錄結構為：
src
----存放java文件
WebRoot
|--images --存放web程序所需的公共圖片
|--css --存放web程序所需的公共樣式表
|--js --存放web程序所需的公共js文件
|--commons --存放web程序所需的公共文件
|--功能模塊文件夾(存放與某個功能模塊相關的資源)
|--images --存放與該功能模塊相關的圖片
|--css --存放與該模塊相關的樣式表文件
|--js --存放與該模塊相關的js文件
|--jsp、html頁面
|--WEB-INF
|--classes
|--lib
|--tld文件
J2EE項目提交規范
項目完成時要將項目作為一個產品交付用戶，良好的項目組織規范可以使用戶可以方便的找尋項目中需要的資源，同時也是一個公司專業性的體現。項目提交時，要按照下列文件格式進行提交。
項目主文件夾：
作用：存放項目其他資源文件。
命名規范：時間_班級編號_第X小組。
例如：070706_GS2T18_第四小組。
項目主文件夾下面包括以下文件夾和文件：
|--src：保存.java文件。
|--database：保存數據庫的腳本文件或者數據庫備份文件。
|--source：保存eclipse工程中WebRoot目錄下的所有文件。
|--depend：保存編譯該程序必須依賴的其他jar文件。
|--javadoc：保存所有類生成的javadoc api文檔。
|--war：保存程序的歸檔文件
|--xx.war：已經打包好的工程文件，可以直接運行。
|--project：保存開發項目原工程代碼及文件。
|--產品說明書.doc：圖文方式展現該產品使用方法。
|--build.xml：ant腳本，用于生成運行的war文件。
|--項目解說.ppt：進行項目講解的ppt（ppt僅供在校模擬項目使用，不用于其他商業用途）
注：一個完整的項目中，數據庫必須有一定量的有效的測試數據來支持該程序的運行
包的命名
Java包的名字都是由小寫單詞組成。但是由于Java面向對象編程的特性，每一名Java程序員都可以編寫屬于自己的Java包，為了保障每個 Java包命名的唯一性，在最新的Java編程規范中，要求程序員在自己定義的包的名稱之前加上唯一的前綴。由于互聯網上的域名稱是不會重復的，所以程序 員一般采用自己在互聯網上的域名稱作為自己程序包的唯一前綴。
例如： net.frontfree.javagroup
類的命名
類的名字必須由大寫字母開頭而單詞中的其他字母均為小寫；如果類名稱由多個單詞組成，則每個單詞的首字母均應為大寫例如TestPage；如果類名 稱中包含單詞縮寫，則這個所寫詞的每個字母均應大寫，如：XMLExample,還有一點命名技巧就是由于類是設計用來代表對象的，所以在命名類時應盡量 選擇名詞。
例如： Circle
方法的命名
方法的名字的第一個單詞應以小寫字母作為開頭，后面的單詞則用大寫字母開頭。
例如： sendMessge
常量的命名
常量的名字應該都使用大寫字母，并且指出該常量完整含義。如果一個常量名稱由多個單詞組成，則應該用下劃線來分割這些單詞。
例如： MAX_VALUE
參數的命名
參數的命名規范和方法的命名規范相同，而且為了避免閱讀程序時造成迷惑，請在盡量保證參數名稱為一個單詞的情況下使參數的命名盡可能明確。
Javadoc注釋
Java除了可以采用我們常見的注釋方式之外，Java語言規范還定義了一種特殊的注釋，也就是我們所說的Javadoc注釋，它是用來記錄我們代 碼中的API的。Javadoc注釋是一種多行注釋，以結束，注釋可以包含一些HTML標記符和專門的關鍵詞。使用Javadoc 注釋的好處是編寫的注釋可以被自動轉為在線文檔，省去了單獨編寫程序文檔的麻煩。
例如：
在每個程序的最開始部分，一般都用Javadoc注釋對程序的總體描述以及版權信息，之后在主程序中可以為每個類、接口、方法、字段添加 Javadoc注釋，每個注釋的開頭部分先用一句話概括該類、接口、方法、字段所完成的功能，這句話應單獨占據一行以突出其概括作用，在這句話后面可以跟 隨更加詳細的描述段落。在描述性段落之后還可以跟隨一些以Javadoc注釋標簽開頭的特殊段落，例如上面例子中的@auther和@version，這 些段落將在生成文檔中以特定方式顯示。
變量和常量命名
變量命名的方法采用匈牙利命名法，基本結構為scope_typeVariableName，它使用3字符前綴來表示數據類型，3個字符的前綴必須 小寫，前綴后面是由表意性強的一個單詞或多個單詞組成的名字，而且每個單詞的首寫字母大寫，其它字母小寫，這樣保證了對變量名能夠進行正確的斷句。例如， 定義一個整形變量，用來記錄文檔數量：intDocCount，其中int表明數據類型，后面為表意的英文名，每個單詞首字母大寫。這樣，在一個變量名就 可以反映出變量類型和變量所存儲的值的意義兩方面內容，這使得代碼語句可讀性強、更加容易理解。byte、int、char、long、float、 double、boolean和short。
變量類型和首字母對照關系如下表：
數據類型/對象類型 / 變量前綴 / 備注
byte bye
char chr
float flt
boolean bln 做布爾變量時，使用bln
Integer/int int
String str
Single sng
short sht
Long/long lng
Double/double dbl
Currency cur
Variant bln astr obj vnt 做布爾變量用時，用bln，做字符串數組用時，用astr，做為對象使用時，用obj，不確定時，用vnt。
對于數組，在數據類型的前綴前再增加一個a，例如字符串數組為astr。對于在多個函數內都要使用的全局變量，在前面再增加“g_”。例如一個全局的字符串變量：g_strUserInfo。
在變量命名時要注意以下幾點：
· 選擇有意義的名字，注意每個單詞首字母要大寫。
· 在一段函數中不使用同一個變量表示前后意義不同的兩個數值。
· i、j、k等只作為小型循環的循環索引變量。
· 避免用Flag來命名狀態變量。
· 用Is來命名邏輯變量，如：blnFileIsFound。通過這種給布爾變量肯定形式的命名方式，使得其它開發人員能夠更為清楚
的理解布爾變量所代表的意義。
· 如果需要的話，在變量最后附加計算限定詞，如：curSalesSum。
· 命名不相包含，curSales和curSalesSum。
· Static Final 變量的名字應該都大寫，并且指出完整含義。
· 如果需要對變量名進行縮寫時，一定要注意整個代碼中縮寫規則的一致性。例如，如果在代碼的某些區域中使用intCnt，而在另一些區域中又使用intCount，就會給代碼增加不必要的復雜性。建議變量名中盡量不要出現縮寫。
· 通過在結尾處放置一個量詞，就可創建更加統一的變量，它們更容易理解，也更容易搜索。例如，請使用 strCustomerFirst和strCustomerLast，而不要使用strFirstCustomer和strLastCustomer。常 用的量詞后綴有：First（一組變量中的第一個）、Last（一組變量中的最后一個）、Next（一組變量中的下一個變量）、Prev（一組變量中的上 一個）、Cur（一組變量中的當前變量）。
· 為每個變量選擇最佳的數據類型，這樣即能減少對內存的需求量，加快代碼的執行速度，又會降低出錯的可能性。用于變量的數據類型可能會影響該變量進行計算所產生的結果。在這種情況下，編譯器不會產生運行期錯誤，它只是迫使該值符合數據類型的要求。這類問題極難查找。
· 盡量縮小變量的作用域。如果變量的作用域大于它應有的范圍，變量可繼續存在，并且在不再需要該變量后的很長時間內仍然占用資源。它們的主要問題是，任何類 中的任何方法都能對它們進行修改，并且很難跟蹤究竟是何處進行修改的。占用資源是作用域涉及的一個重要問題。對變量來說，盡量縮小作用域將會對應用程序的 可靠性產生巨大的影響。
關于常量的命名方法，在JAVA代碼中，無論什么時候，均提倡應用常量取代數字、固定字符串。也就是說，程序中除0，1以外，盡量不應該出現其他數 字。常量可以集中在程序開始部分定義或者更寬的作用域內，名字應該都使用大寫字母，并且指出該常量完整含義。如果一個常量名稱由多個單詞組成，則應該用下 劃線“_”來分割這些單詞如：NUM_DAYS_IN_WEEK、MAX_VALUE。