synchronized關鍵字可以作為函式的修飾符，也可作為函式內的語句，也就是平時說的同步方法和同步語句塊。如果再細的分類，synchronized可作用於instance變數、object reference(物件引用)、static函式和class literals(類名稱字面常量)身上。
在進一步闡述之前，我們需要明確幾點：
A.無論synchronized關鍵字加在方法上還是物件上，它取得的鎖都是物件，而不是把一段程式碼或函式當作鎖――而且同步方法很可能還會被其他執行緒的物件訪問。
B.每個物件只有一個鎖(lock)與之相關聯。
C.實現同步是要很大的系統開銷作為代價的，甚至可能造成死鎖，所以儘量避免無謂的同步控制。
接著來討論synchronized用到不同地方對程式碼產生的影響：
假設P1、P2是同一個類的不同物件，這個類中定義了以下幾種情況的同步塊或同步方法，P1、P2就都可以呼叫它們。
1. 把synchronized當作函式修飾符時，示例程式碼如下：
Public synchronized void methodAAA()
{
//….
}
這也就是同步方法，那這時synchronized鎖定的是哪個物件呢?它鎖定的是呼叫這個同步方法物件。也就是說，當一個物件P1在不同的執行緒中執行這個同步方法時，它們之間會形成互斥，達到同步的效果。但是這個物件所屬的Class所產生的另一物件P2卻可以任意呼叫這個被加了synchronized關鍵字的方法。
上邊的示例程式碼等同於如下程式碼：
public void methodAAA()
{
synchronized (this) // (1)
{
//…..
}
}
(1)處的this指的是什麼呢?它指的就是呼叫這個方法的物件，如P1。可見同步方法實質是將synchronized作用於object reference。――那個拿到了P1物件鎖的執行緒，才可以呼叫P1的同步方法，而對P2而言，P1這個鎖與它毫不相干，程式也可能在這種情形下襬脫同步機制的控制，造成資料混亂。
2.同步塊，示例程式碼如下：
public void method3(SomeObject so)
{
synchronized(so)
{
//…..
}
}
這時，鎖就是so這個物件，誰拿到這個鎖誰就可以執行它所控制的那段程式碼。當有一個明確的物件作為鎖時，就可以這樣寫程式，但當沒有明確的物件作為鎖，只是想讓一段程式碼同步時，可以建立一個特殊的instance變數(它得是一個物件)來充當鎖：
class Foo implements Runnable
{
private byte[] lock = new byte[0]; // 特殊的instance變數
Public void methodA()
{
synchronized(lock) { //… }
}
//…..
}
注：零長度的byte陣列物件建立起來將比任何物件都經濟――檢視編譯後的位元組碼：生成零長度的byte[]物件只需3條操作碼，而Object lock = new Object()則需要7行操作碼。
3.將synchronized作用於static 函式，示例程式碼如下：
Class Foo
{
public synchronized static void methodAAA() // 同步的static 函式
{
//….
}
public void methodBBB()
{
synchronized(s) // class literal(類名稱字面常量)
}
}
程式碼中的methodBBB()方法是把class literal作為鎖的情況，它和同步的static函式產生的效果是一樣的，取得的鎖很特別，是當前呼叫這個方法的物件所屬的類(Class，而不再是由這個Class產生的某個具體物件了)。
記得在《Effective Java》一書中看到過將 s和 lass()用於作同步鎖還不一樣，不能用lass()來達到鎖這個Class的目的。P1指的是由Foo類產生的物件。
可以推斷：如果一個類中定義了一個synchronized的static函式A，也定義了一個synchronized 的instance函式B，那麼這個類的同一物件Obj在多執行緒中分別訪問A和B兩個方法時，不會構成同步，因為它們的鎖都不一樣。A方法的鎖是Obj這個物件，而B的鎖是Obj所屬的.那個Class。
小結如下：
搞清楚synchronized鎖定的是哪個物件，就能幫助我們設計更安全的多執行緒程式。
還有一些技巧可以讓我們對共享資源的同步訪問更加安全：
1. 定義private 的instance變數+它的 get方法，而不要定義public/protected的instance變數。如果將變數定義為public，物件在外界可以繞過同步方法的控制而直接取得它，並改動它。這也是JavaBean的標準實現方式之一。
2.如果instance變數是一個物件，如陣列或ArrayList什麼的，那上述方法仍然不安全，因為當外界物件通過get方法拿到這個instance物件的引用後，又將其指向另一個物件，那麼這個private變數也就變了，豈不是很危險。這個時候就需要將get方法也加上synchronized同步，並且，只返回這個private物件的clone()――這樣，呼叫端得到的就是物件副本的引用了。
如果不再需要某個類，則該類在堆中所佔用的空間通常將用於建立新物件。但是，如果應用程式通過建立類的新例項來處理請求，並且該應用程式的請求是隨機出現的，則可能會發生以下情況：先前請求者完成後，正常的類垃圾回收將通過釋放這個類佔用的堆空間來清除這個類，但當下一個請求出現時，又必須將這個類重新例項化。在這種情況下，您可能想使用此選項來禁用類垃圾回收。
預設值：
啟用類垃圾回收
建議值：
禁用類垃圾回收
用法：
Xnoclassgc 禁用類垃圾回收
有關其他資訊，請參閱下列 DeveloperWorks 文章：
調整 Sun JVM 的垃圾回收器
在 Solaris 平臺上，WebSphere Application Server 在 Sun Hotspot JVM 上執行，而不是在 IBM JVM 上執行。對 Sun JVM 使用正確的調整引數以利用其效能優化功能十分重要。
Sun Hotspot JVM 依靠分代垃圾回收來實現最佳效能。下列命令列引數對於調整垃圾回收來說非常有用。
-XX:SurvivorRatio
將 Java 堆劃分為舊物件(長生命週期物件)區域和新物件區域。新物件區域進一步細分為兩部分，第一部分用於分配給新物件(初始區域)，第二部分存放那些經過其前幾次垃圾回收之後、但在被提升為舊物件之前仍在使用中的新物件(倖存者空間)。倖存者比率是堆的新物件區域中初始區域與倖存者空間的比率。增大此設定將針對需要建立大量物件但僅保留少量物件的應用程式優化 JVM。與其他應用程式相比，WebSphere Application Server 會生成更多中等生命週期物件和長生命週期物件，因此，應該將此設定設定為小於預設值。
預設值：
32
建議值：
16
用法：
-XX:SurvivorRatio=16
-XX:PermSize
為永久生成物件保留的堆區域儲存 JVM 的所有反射資料。對於動態地裝入和解除安裝大量類的應用程式來說，應該增大此大小以優化它們的效能。通過將此引數設定為 128MB，可以消除增大此部分堆所需的開銷。
建議值：
128 MB
用法：
XX:PermSize=128m 將 perm 大小設定為 128 兆位元組。
-Xmn
此設定控制允許新生成的物件在堆中耗用的空間量。正確調整此引數有助於降低垃圾回收開銷，從而縮短伺服器響應時間並提高吞吐量。此引數的預設設定通常過低，這將導致執行大量的小型垃圾回收操作。如果將此引數設定得過高，可能會導致 JVM 僅執行大型(全面)垃圾回收。這些垃圾回收操作通常會耗時幾秒鐘，這將嚴重影響伺服器的整體效能。您必須保持將此引數設定為小於整個堆大小的一半，以避免這種情況出現。
預設值：
2228224 位元組
建議值：
大約整個堆大小的 1/4
用法：
-Xmn256m 將大小設定為 256 兆位元組。
-Xnoclassgc
預設情況下，當一個類沒有任何活動例項時，JVM 就會從記憶體中解除安裝該類，但是這樣會使效能下降。如果關閉類垃圾回收，就可以消除由於多次裝入和解除安裝同一個類而造成的開銷。
如果不再需要某個類，則該類在堆中所佔用的空間通常將用於建立新物件。但是，如果應用程式通過建立類的新例項來處理請求，並且該應用程式的請求是隨機出現的，則可能會發生以下情況：先前請求者完成後，正常的類垃圾回收將通過釋放這個類佔用的堆空間來清除這個類，但當下一個請求出現時，又必須將這個類重新例項化。在這種情況下，您可能想使用此選項來禁用類垃圾回收。
預設值：
啟用類垃圾回收
建議值：
禁用類垃圾回收
用法：
Xnoclassgc 禁用類垃圾回收
有關調整 Sun JVM 的其他資訊，請參閱 Java HotSpot VM 的效能文件。
調整 HP JVM 的垃圾回收器
HP JVM 依靠分代垃圾回收來實現最佳效能。下列命令列引數對於調整垃圾回收來說非常有用。
-Xoptgc
此設定針對包含許多短生命週期物件的應用程式優化 JVM。如果未指定此引數，則 JVM 通常執行大型(全面)垃圾回收。全面垃圾回收會花費幾秒鐘時間，這將顯著影響伺服器效能。
預設值：
off
建議值：
on
用法：
-Xoptgc 啟用優化的垃圾回收。
-XX:SurvivorRatio
將 Java 堆劃分為舊物件(長生命週期物件)區域和新物件區域。新物件區域進一步細分為兩部分，第一部分用於分配給新物件(初始區域)，第二部分存放那些經過其前幾次垃圾回收之後、但在被提升為舊物件之前仍在使用中的新物件(倖存者空間)。倖存者比率是堆的新物件區域中初始區域與倖存者空間的比率。增大此設定將針對需要建立大量物件但僅保留少量物件的應用程式優化 JVM。與其他應用程式相比，WebSphere Application Server 會生成更多中等生命週期物件和長生命週期物件，因此，應該將此設定設定為小於預設值。
預設值：
32
建議值：
16
用法：
-XX:SurvivorRatio=16
-XX:PermSize
為永久生成物件保留的堆區域儲存 JVM 的所有反射資料。對於動態地裝入和解除安裝大量類的應用程式來說，應該增大此大小以優化它們的效能。通過將此引數指定為 128 兆位元組，可以消除增大此部分堆所需的開銷。
預設值：
0
建議值：
128 兆位元組
用法：
-XX:PermSize=128m 將 PermSize 設定為 128 兆位元組
-XX:+ForceMmapReserved
預設情況下，Java 堆以“惰性交換”方式進行分配。在此方式下，將根據需要來分配記憶體頁，這樣可以節省交換空間，但是也將強制使用 4KB 頁。在大型堆系統中，這種記憶體分配方式允許堆包含數以十萬計的頁。此命令禁用“惰性交換”並允許作業系統使用較大的記憶體頁，從而優化對構成 Java 堆的記憶體的訪問。
預設值：
off
建議值：
on
用法：
-XX:+ForceMmapReserved 將禁用“惰性交換”。
-Xmn
此設定控制允許新生成的物件在堆中耗用的空間量。正確調整此引數有助於降低垃圾回收開銷，從而縮短伺服器響應時間並提高吞吐量。此引數的預設設定通常過低，這將導致執行大量的小型垃圾回收操作。
預設值：
沒有預設值
建議值：
大約整個堆大小的 3/4
用法：
-Xmn768m 將大小設定為 768 兆位元組
虛擬頁大小
通過將 Java 虛擬機器的指令頁大小和資料頁大小設定為 64MB，可以提高效能。
預設值：
4MB
建議值：
64MB
用法：
使用以下命令。命令輸出提供了程序可執行檔案的當前作業系統特徵：
chatr +pi64M +pd64M /opt/WebSphere/
AppServer/java/bin/PA_RISC2.0/
native_threads/java -Xnoclassgc
預設情況下，當一個類沒有任何活動例項時，JVM 就會從記憶體中解除安裝該類，但是這樣會使效能下降。如果關閉類垃圾回收，就可以消除由於多次裝入和解除安裝同一個類而造成的開銷。
如果不再需要某個類，則該類在堆中所佔用的空間通常將用於建立新物件。但是，如果應用程式通過建立類的新例項來處理請求，並且該應用程式的請求是隨機出現的，則可能會發生以下情況：先前請求者完成後，正常的類垃圾回收將通過釋放這個類佔用的堆空間來清除這個類，但當下一個請求出現時，又必須將這個類重新例項化。在這種情況下，您可能想使用此選項來禁用類垃圾回收。
預設值：
啟用類垃圾回收
建議值：
禁用類垃圾回收
用法：
Xnoclassgc 禁用類垃圾回收
有關調整 HP 虛擬機器的其他資訊，請參閱 Java 技術軟體 HP-UX 11i。
調整 HP 的 JVM for HP-UX 設定下列選項以提高應用程式效能：
-XX:SchedulerPriorityRange=SCHED_NOAGE
ctorProvider=ollSelectorProvider
-XX:-ExtraPollBeforeRead
