Synchronized造成效能低落嗎? 試試樂觀同步化吧!!
前陣子調效一個Web Application的效能,在貢獻了許多咖啡因到腦袋後,我找到了原因-- Synchronized
是的,在某支Servlet中的某函式使用了Synchronized關鍵字,造成系統在此排隊執行,因而效能低落,於是立刻招開小組會議,但幾經測試及討論後,卻發現此區塊一定得同步化,否則發生Race Condition時,會造成資料錯誤…
我效能調效的工作遇到了瓶頸…Orz
...
...
幾經思量,我決定將此函式改造成使用樂觀同步化技術!!
什麼是樂觀同步化?
使用Java寫作的程式,通常在可能會發生同時存取共用資料的情形時,使用Synchronized關鍵字,以確保同一時間只會有一個Thread執行這段程式,但這種作法就是所謂的悲觀同步化,問題解決了,但代價可能是會有多個Thread在排隊等候,造成效能低落。
樂觀同步化則樂觀的認為同時存取的情形很少發生,萬一發生的話,再補救就好了。
說明看起來很簡單,但使用較早期版本的JDK要實作可不簡單,幸運的是,JDK從1.5之後引進了Atomic類別庫,讓你可以方便的實作樂觀同步化。
Race Condition
在開始之前,先來看看什麼是「同時存取共用資料」,這個問題學名叫「Race Condition」,就是指共用的資料,幾乎同時間被許多不同的Thread存取,造成資料不一致的問題。
讓我們來看個例子:
有個定貨系統,使用了三個執行緒在處理同一個產品的訂單,訂單在產生之前必須先更新產品的資料。
產品物件的定義如下:
public class MyProduct {
private String productId;
private double price;
private String description;
public MyProduct(String productId, double price, String description) {
this.productId = productId;
this.price = price;
this.description = description;
}
public String toString() {
return productId +
"(NT$ " + price +
", " + description + ")";
}
public boolean equals(Object anObject) {
MyProduct newProduct = (MyProduct) anObject;
return productId.equals(newProduct.getProductId()) &&
price == newProduct.getPrice() &&
description.equals(newProduct.getDescription());
}
public void createOrderTO() {
// 用一段sleep來模擬產生訂單需要執行的時間
try {
long rnd = (long)(java.lang.Math.random() * 100);
Thread.sleep(rnd);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public String getDescription() {
return description;
}
public void setDescription(String description) {
this.description = description;
}
public double getPrice() {
return price;
}
public void setPrice(double price) {
this.price = price;
}
public String getProductId() {
return productId;
}
public void setProductId(String productId) {
this.productId = productId;
}
}
處理訂單的執行緒程式如下:
public class ProductProcessor implements Runnable {
public ProductProcessor(int id) {
processorId = id;
}
private int processorId;
public int getProcessorId() {
return processorId;
}
private MyProduct product;
public void setProduct(MyProduct product) {
this.product = product;
}
/* (non-Javadoc)
* @see java.lang.Runnable#run()
*/
public void run() {
// 每個thread對此產品產生5個訂單
for (int i = 0; i < 5; i++) {
// 更新產品資料
product.setPrice(processorId * 10);
product.setDescription(
"modified by processor: " + processorId
);
// 跟據product產生訂單物件(Order Transfer Object)
product.createOrderTO();
// 列印訂單
System.out.println("Processor " + processorId +
" Create Order for: " + product.toString());
}
}
public static void main(String args[]) {
// 產生一個product
MyProduct prod = new MyProduct("my_product_01", 9999999, "this is my product!");
ProductProcessor p1 = new ProductProcessor(1);
ProductProcessor p2 = new ProductProcessor(2);
ProductProcessor p3 = new ProductProcessor(3);
// 讓三個thread都一起存取同一個Product
p1.setProduct(prod);
p2.setProduct(prod);
p3.setProduct(prod);
Thread t1 = new Thread(p1);
Thread t2 = new Thread(p2);
Thread t3 = new Thread(p3);
t1.start();
t2.start();
t3.start();
}
}
執行結果如下:
Processor 3 Create Order for: my_product_01(NT$ 30.0, modified by processor: 3)
Processor 2 Create Order for: my_product_01(NT$ 30.0, modified by processor: 3)
Processor 3 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
Processor 1 Create Order for: my_product_01(NT$ 30.0, modified by processor: 3)
Processor 3 Create Order for: my_product_01(NT$ 10.0, modified by processor: 1)
Processor 1 Create Order for: my_product_01(NT$ 30.0, modified by processor: 3)
Processor 2 Create Order for: my_product_01(NT$ 10.0, modified by processor: 1)
Processor 1 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
Processor 3 Create Order for: my_product_01(NT$ 10.0, modified by processor: 1)
Processor 1 Create Order for: my_product_01(NT$ 30.0, modified by processor: 3)
Processor 2 Create Order for: my_product_01(NT$ 10.0, modified by processor: 1)
Processor 1 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
Processor 3 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
Processor 2 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
Processor 2 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
從結果可以發現許多衝突,例如第2行Processor 2產生的訂單,其說明卻註記說是Processor 3更新的。
這種衝突的情現就叫Race Condition。
悲觀同步化
要如何解決Race condition呢? 最簡單的方法就是使用Synchronized區塊了:
在有可能發生Race Condition的地方,使用Synchronize {}把這些程式碼都包起來,就可以解決問題,像下面這樣:
// use synchronized block to solve race condition
synchronized (product) {
// 更新產品資料
product.setPrice(processorId * 10);
product.setDescription(
"modified by processor: " + processorId
);
// 跟據product產生訂單物件(Order Transfer Object)
product.createOrderTO();
// 列印訂單
System.out.println("Processor " + processorId +
" Create Order for: " + product.toString());
}
再執行一次,我們可以得到完美的結果:
Processor 1 Create Order for: my_product_01(NT$ 10.0, modified by processor: 1)
Processor 2 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
Processor 3 Create Order for: my_product_01(NT$ 30.0, modified by processor: 3)
Processor 1 Create Order for: my_product_01(NT$ 10.0, modified by processor: 1)
Processor 2 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
Processor 3 Create Order for: my_product_01(NT$ 30.0, modified by processor: 3)
...
...
這個技巧就是悲觀同步化,Java保證synchronized區塊同時只會有一個執行緒進入存取product物件,因此Race Condition不會再發生,但有時這種解法會造成效能低落。
樂觀同步化
在大多數情況下,其實Race Condition是很少發生的;當衝突很少發生,卻使用悲觀管控,就好像是「交通部長要求交通警察限制同一時間只能有一台車上高速公路一樣」,可以想見交流道口會塞的又臭又長。
所以樂觀同步化就派上用場了,基本原理很簡單:「如果發生衝突,就重做」!
JDK 1.5之後提供了AtomicInteger、AtomicLong、AtomicBoolean、AtomicReference…等類別讓你可以不使用lock卻能解決Race Condition。
這些類別的特色是裡面的方法都是Atomic的,也就是所有的方法都可以視作單一的一種操作,不會受其它Thread的影響。例如:
AtomicInteger ival = new AtomicInteger(1);
ival.set(5); // 這個操作是Atomic的
// 如果ival==5的話就把ival的值改成10 (這個操作也是Atomic的)
ival.compareAndSet(5, 10);
(注:你可能覺得ival.set(5)和宣告成一般的int然後執行ival=5;有什麼不同,但其實用一般的int,其操作還是沒有Atomic,這遷涉到byte code的內容和register的載入方式,以後有機會再聊聊。)
使用AtomicReference
思考一下前述發生問題的程式,如果以下三個步驟:
// 更新產品資料
...
// 跟據product產生訂單物件(Order Transfer Object)
...
// 列印訂單
...
可以結合成一個Atomic的動作,那不就不需要再使用synchronized關鍵字了嗎?
問題是,要怎麼做呢? 我們可以使用AtomicReference將MyProduct包裝一下,像這樣:
import java.util.concurrent.atomic.AtomicReference;
public class MyAtomicProduct{
private AtomicReference
public MyAtomicProduct(String productId, double price, String description) {
product = new AtomicReference
( new MyProduct(productId, price, description) );
}
public void updateProductAndMakeOrder(int processorId,
double price,
String description) {
MyProduct origVal, newVal;
String origProductId;
// 這是一個無窮迴圈,會一直重做到沒有發生Race Condition為止
while (true) {
origVal = product.get();
origProductId = origVal.getProductId();
// 記住使用AtomicReference在設定值的時候一定要指派一個新的
newVal = new MyProduct(origProductId, price, description);
// 跟據product產生訂單物件(Order Transfer Object)
newVal.createOrderTO();
// compareAndSet會確保product的值和原來(origVal)一樣時
// ,才會將product的值更新,否則就不做事且傳回false
// (如果不一樣表示過程中有其他的thread進來,也就是Race Condition
// 當發生Race Condition時,迴圈就會重做)
if (product.compareAndSet(origVal, newVal)) {
System.out.println("Processor " + processorId +
" Create Order for: " + newVal.toString());
break; // 產生的訂單是正確的,所以結束迴圈
} else {
// Debug用,在此特別將發生Race Condition而重做的情形印出來
System.out.println("** [Redo] because of Race Condition! **");
}
}
}
}
然後把void main中產生product的那行改成如下
MyAtomicProduct prod = new MyAtomicProduct("my_product_01", 9999999, "this is my product!");
執行結果如下:
Processor 3 Create Order for: my_product_01(NT$ 30.0, modified by processor: 3)
Processor 3 Create Order for: my_product_01(NT$ 30.0, modified by processor: 3)
** [Redo] because of Race Condition! **
** [Redo] because of Race Condition! **
Processor 1 Create Order for: my_product_01(NT$ 10.0, modified by processor: 1)
Processor 1 Create Order for: my_product_01(NT$ 10.0, modified by processor: 1)
** [Redo] because of Race Condition! **
** [Redo] because of Race Condition! **
Processor 1 Create Order for: my_product_01(NT$ 10.0, modified by processor: 1)
** [Redo] because of Race Condition! **
** [Redo] because of Race Condition! **
Processor 1 Create Order for: my_product_01(NT$ 10.0, modified by processor: 1)
** [Redo] because of Race Condition! **
Processor 3 Create Order for: my_product_01(NT$ 30.0, modified by processor: 3)
** [Redo] because of Race Condition! **
** [Redo] because of Race Condition! **
Processor 2 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
** [Redo] because of Race Condition! **
** [Redo] because of Race Condition! **
Processor 2 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
Processor 2 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
** [Redo] because of Race Condition! **
** [Redo] because of Race Condition! **
Processor 3 Create Order for: my_product_01(NT$ 30.0, modified by processor: 3)
** [Redo] because of Race Condition! **
** [Redo] because of Race Condition! **
Processor 3 Create Order for: my_product_01(NT$ 30.0, modified by processor: 3)
** [Redo] because of Race Condition! **
** [Redo] because of Race Condition! **
Processor 1 Create Order for: my_product_01(NT$ 10.0, modified by processor: 1)
** [Redo] because of Race Condition! **
Processor 2 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
Processor 2 Create Order for: my_product_01(NT$ 20.0, modified by processor: 2)
可以發現當Race Condition發生時,迴圈會重做以確保資料正確,在衝突不常發生的情形下,使用樂觀同步化是有可能解決效能低落的狀況的,不過如果Race Condition常常發生,則值不值得就見人見智了,更何況實作樂觀同步化會使你的系統更複雜了。