java併發編程使用鎖進行數據同步操做一

    項目中老是出現招標項目超投的狀況，最開始老是以爲應該使用框架Hibernate自帶的併發策略中的樂觀鎖（version）解決問題，參考了不少網上的資料，也參考了Hibernate的幫助文檔，因爲對Hibernate樂觀鎖機制不瞭解，問題就一直沒有解決。

    最近在看Java併發編程相關知識，瞭解了些許併發，線程，鎖的知識。想到了這個問題，曾經使用Synchroized關鍵字時老是苦於沒法獲取同一個對象，致使解決方案無效。此次採用的方案是：建立了靜態的HashMap<Integer,Lock>,初始化必定數量的對象（可結合服務器的性能來確認對象的數量），採用公平模式競爭鎖，在處理業務數據。

package com;
import java.util.HashMap;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class testMain {
/**
 * test類
 * @param args
 */
public static void main(String[] args) {
// TODO Auto-generated method stub
testOut testOut=new testOut();
outPut o =new outPut(testOut);
//模擬併發三個線程
new Thread(o,"first").start();
new Thread(o,"second").start();
new Thread(o,"thread").start();
}
}
/**
 * 線程類
 * @author linyan
 *
 */
class outPut implements Runnable{
private testOut testOut;
public outPut(testOut t){
testOut=t;
}
@Override
public void run() {
// TODO Auto-generated method stub
testOut.sysout(20);
}
}
/**
 * 業務處理方法
 * @author linyan
 *
 */
class testOut{
/**
 * 建立靜態map
 * 初始化map對象
 */
public final static HashMap<Integer,Lock> map=new HashMap<Integer,Lock>();
static{
for(int i=0;i<2;i++){
//初始化公平鎖，確保等待時間最久的線程得到鎖
map.put(i, new ReentrantLock(true));
}
}
private int number=0;
public void sysout(int i){
System.out.println(Thread.currentThread().getName()+":"+i);
//模擬同一個招標項目的標的編號來爭搶鎖
int index=i%map.size();
try{
map.get(index).lock();
//TOOD  業務邏輯處理方法
number=number+i;
//輸出當前得到線程的鎖及請求參數
System.out.println(Thread.currentThread().getName()+":"+index);
//得到當前線程內查看到的活動線程數
System.out.println(Thread.currentThread().getName()+":"+Thread.currentThread().activeCount());
//輸出對應累加的數值
System.out.println(Thread.currentThread().getName()+"="+number);
}finally{
map.get(index).unlock();
}
}
public int getNumber() {
return number;
}
public void setNumber(int number) {
this.number = number;
}
}

對應的輸出結果：

thread:20
first:20
first:0
first:4
first=20
second:20
thread:0
thread:3
thread=40
second:0
second:2
second=60

    通過反覆的測試，輸出的結果都和預期一致，故斷定這一解決方案有效。將解決方案放到具體項目上實施，結果仍然出現了超投問題，通過問題定位發現，在業務邏輯處理中業務邏輯的事務分割範圍太寬，致使了數據不能當即入庫，同時Hibernate的查詢仍與緩存交互，不是實時查詢數據庫，致使繼續超投的狀況。

    事務範圍切割問題很好解決，可是對Hibernate查詢問題一直沒有解決，爲了解決問題，採用了臨時方案：建立JDBC鏈接來實時查詢。最終以犧牲了部分性能爲代價，解決這個問題，最近在研究一下Hibernate查詢方式，看是否能用Hibernate的實時查詢。