1、文件鎖
如果對該表的更新或插入的操作，都會經過一個統一的文件，這種方式是可以解決的多進程並發的問題；
實現方式如下：
public static function cbInventoryReserve() {
$LOCK_FILE_PATH = $_SERVER['DOCUMENT_ROOT']."wmsinventoryapi/inventory/InventoryReserve.php";
$fp = fopen( $LOCK_FILE_PATH, "r" );
if (!$fp) {
die("Failed to open the lock file!");
}
flock ( $fp, LOCK_EX );
//需要進行的操作
$params = Flight::request()->getBody();
$params = json_decode($params, true);
if (! is_array($params) || empty($params)) {
Flight::sendRouteResult(array("error_code" => "40002","error_info" => "params empty"));
}
$result = \Inventory\InventoryEngine::getInstance()->inventoryReserve($params);
flock ( $fp, LOCK_UN );
fclose ( $fp );
Flight::sendRouteResult($result);
}
函數說明 flock()會依參數operation所指定的方式對參數fd所指的文件做各種鎖定或解除鎖定的動作。此函數只能鎖定整個文件，無法鎖定文件的某一區域。
參數 operation有下列四種情況:
LOCK_SH 建立共享鎖定。多個進程可同時對同一個文件作共享鎖定。
LOCK_EX 建立互斥鎖定。一個文件同時只有一個互斥鎖定。
LOCK_UN 解除文件鎖定狀態。
LOCK_NB 無法建立鎖定時，此操作可不被阻斷，馬上返回進程。通常與LOCK_SH或LOCK_EX 做OR(|)組合。
單一文件無法同時建立共享鎖定和互斥鎖定，而當使用dup()或fork()時文件描述詞不會繼承此種鎖定。
返回值 返回0表示成功，若有錯誤則返回-1，錯誤代碼存於errno。
換言之：
使用共享鎖LOCK_SH，如果是讀取，不需要等待，但如果是寫入，需要等待讀取完成。
使用獨占鎖LOCK_EX，無論寫入/讀取都需要等待。
LOCK_UN，無論使用共享/讀占鎖，使用完后需要解鎖。
LOCK_NB，當被鎖定時，不阻塞，而是提示鎖定。
為了更好的移植性，對於文件的打開與關閉我選擇了fopen和fclose的組合，但flock的第一個參數要求的是int類型的文件描述符。這里對fopen返回的FILE類型的文件指針進行轉換，轉換為int型的文件描述符 （假設open函數返回的文件描述符為fd，而fopen返回的文件指針為*fp，則fd等價於fp->_fileno）.
2、序列化接口（對象序列化）
所有php里面的值都可以使用函數serialize()來返回一個包含字節流的字符串來表示。unserialize()函數能夠重新把字符串變回php原來的值。 序列化一個對象將會保存對象的所有變量，但是不會保存對象的方法，只會保存類的名字。
<?php
// classa.inc:
class A {
public $one = 1;
public function show_one() {
echo $this->one;
}
}
// page1.php:
include("classa.inc");
$a = new A;
$s = serialize($a);
// 把變量$s保存起來以便文件page2.php能夠讀到
file_put_contents('store', $s);
// page2.php:
// 要正確了解序列化，必須包含下面一個文件
include("classa.inc");
$s = file_get_contents('store');
$a = unserialize($s);
// 現在可以使用對象$a里面的函數 show_one()
$a->show_one();
?>
3、select *** for update
Select …forupdate語句是我們經常使用手工加鎖語句。通常情況下，select語句是不會對數據加鎖，妨礙影響其他的DML和DDL操作。同時，在多版本一致讀機制的支持下，select語句也不會被其他類型語句所阻礙。
借助for update子句，我們可以在應用程序的層面手工實現數據加鎖保護操作。
for update子句的默認行為就是自動啟動一個事務，借助事務的鎖機制將數據進行鎖定。
開啟一個事務使用for update
start transaction; select sum(quantity) from ws_inventory_item where inventory_item_id=86 for update;
再開啟另一個事務時，做update 操作的時，只能等待上面的事務，commit才能執行；
start transaction; update ws_inventory_item set quantity = quantity + 1 where inventory_item_id = 86;
SELECT … LOCK IN SHARE MODE SELECT … FOR UPDATE
SELECT quantity FROM products WHERE id=3; UPDATE products SET quantity = 1 WHERE id=3;
1 SET AUTOCOMMIT=0; 2 BEGIN WORK; 3 SELECT quantity FROM products WHERE id=3 FOR UPDATE;
1 UPDATE products SET quantity = '1' WHERE id=3 ; 2 COMMIT WORK;
SELECT * FROM products WHERE id='3' FOR UPDATE;
SELECT * FROM products WHERE id='-1' FOR UPDATE;
SELECT * FROM products WHERE name='Mouse' FOR UPDATE;
SELECT * FROM products WHERE id<>'3' FOR UPDATE;
SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;
4、事務隔離級別
如何解決多進程或多線程並發問題
本節轉載，原文地址：http://singo107.iteye.com/blog/1175084
數據庫事務的隔離級別有4個，由低到高依次為Read uncommitted、Read committed、Repeatable read、Serializable，這四個級別可以逐個解決臟讀、不可重復讀、幻讀這幾類問題。
√: 可能出現 ×: 不會出現
| 臟讀 | 不可重復讀 | 幻讀 | |
| Read uncommitted | √ | √ | √ |
| Read committed | × | √ | √ |
| Repeatable read | × | × | √ |
| Serializable | × | × | × |
注意：我們討論隔離級別的場景，主要是在多個事務並發的情況下，因此，接下來的講解都圍繞事務並發。
Read uncommitted 讀未提交
公司發工資了，領導把5000元打到singo的賬號上，但是該事務並未提交，而singo正好去查看賬戶，發現工資已經到賬，是5000元整，非常高興。可是不幸的是，領導發現發給singo的工資金額不對，是2000元，於是迅速回滾了事務，修改金額后，將事務提交，最后singo實際的工資只有2000元，singo空歡喜一場。
出現上述情況，即我們所說的臟讀，兩個並發的事務，“事務A：領導給singo發工資”、“事務B：singo查詢工資賬戶”，事務B讀取了事務A尚未提交的數據。
當隔離級別設置為Read uncommitted時，就可能出現臟讀，如何避免臟讀，請看下一個隔離級別。
Read committed 讀提交
singo拿着工資卡去消費，系統讀取到卡里確實有2000元，而此時她的老婆也正好在網上轉賬，把singo工資卡的2000元轉到另一賬戶，並在singo之前提交了事務，當singo扣款時，系統檢查到singo的工資卡已經沒有錢，扣款失敗，singo十分納悶，明明卡里有錢，為何......
出現上述情況，即我們所說的不可重復讀，兩個並發的事務，“事務A：singo消費”、“事務B：singo的老婆網上轉賬”，事務A事先讀取了數據，事務B緊接了更新了數據，並提交了事務，而事務A再次讀取該數據時，數據已經發生了改變。
當隔離級別設置為Read committed時，避免了臟讀，但是可能會造成不可重復讀。
大多數數據庫的默認級別就是Read committed，比如Sql Server , Oracle。如何解決不可重復讀這一問題，請看下一個隔離級別。
Repeatable read 重復讀
當隔離級別設置為Repeatable read時，可以避免不可重復讀。當singo拿着工資卡去消費時，一旦系統開始讀取工資卡信息（即事務開始），singo的老婆就不可能對該記錄進行修改，也就是singo的老婆不能在此時轉賬。
雖然Repeatable read避免了不可重復讀，但還有可能出現幻讀。
singo的老婆工作在銀行部門，她時常通過銀行內部系統查看singo的信用卡消費記錄。有一天，她正在查詢到singo當月信用卡的總消費金額（select sum(amount) from transaction where month = 本月）為80元，而singo此時正好在外面胡吃海塞后在收銀台買單，消費1000元，即新增了一條1000元的消費記錄（insert transaction ... ），並提交了事務，隨后singo的老婆將singo當月信用卡消費的明細打印到A4紙上，卻發現消費總額為1080元，singo的老婆很詫異，以為出現了幻覺，幻讀就這樣產生了。
注：Mysql的默認隔離級別就是Repeatable read。
Serializable 序列化
Serializable是最高的事務隔離級別，同時代價也花費最高，性能很低，一般很少使用，在該級別下，事務順序執行，不僅可以避免臟讀、不可重復讀，還避免了幻像讀。
Mysql事務隔離級別設置方式
用戶可以用SET TRANSACTION語句改變單個會話或者所有新進連接的隔離級別。它的語法如下：
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}
注意：默認的行為（不帶session和global）是為下一個（未開始）事務設置隔離級別。如果你使用GLOBAL關鍵字，語句在全局對從那點開始創建的所有新連接（除了不存在的連接）設置默認事務級別。你需要SUPER權限來做這個。使用SESSION 關鍵字為將來在當前連接上執行的事務設置默認事務級別。 任何客戶端都能自由改變會話隔離級別（甚至在事務的中間），或者為下一個事務設置隔離級別。
Java 多線程並發編程會有許多不同的問題，主要有如下問題的應用：
- 多線程讀寫共享數據同步問題
- 並發讀數據，保持各個線程讀取到的數據一致性的問題。
解決方案：
- synchronized關鍵字和Lock並發鎖：主要解決多線程共享數據同步問題。
- ThreadLocal主要解決多線程中數據因並發產生不一致問題。
ThreadLocal與synchronized有本質的區別:
ThreadLocal是什么？
早在JDK 1.2的版本中就提供Java.lang.ThreadLocal，ThreadLocal為解決多線程程序的並發問題提供了一種新的思路。使用這個工具類可以很簡潔地編寫出優美的多線程程序。
ThreadLocal很容易讓人望文生義，想當然地認為是一個“本地線程”。其實，ThreadLocal並不是一個Thread，而是Thread的局部變量，也許把它命名為ThreadLocalVariable更容易讓人理解一些。
當使用ThreadLocal維護變量時，ThreadLocal為每個使用該變量的線程提供獨立的變量副本，所以每一個線程都可以獨立地改變自己的副本，而不會影響其它線程所對應的副本。
從線程的角度看，目標變量就象是線程的本地變量，這也是類名中“Local”所要表達的意思。
線程局部變量並不是Java的新發明，很多語言（如IBM IBM XL FORTRAN）在語法層面就提供線程局部變量。在Java中沒有提供在語言級支持，而是變相地通過ThreadLocal的類提供支持。
所以，在Java中編寫線程局部變量的代碼相對來說要笨拙一些，因此造成線程局部變量沒有在Java開發者中得到很好的普及。
ThreadLocal的接口方法
ThreadLocal類接口很簡單，只有4個方法，我們先來了解一下：
void set(Object value)
設置當前線程的線程局部變量的值。
public Object get()
該方法返回當前線程所對應的線程局部變量。
public void remove()
將當前線程局部變量的值刪除，目的是為了減少內存的占用，該方法是JDK 5.0新增的方法。需要指出的是，當線程結束后，對應該線程的局部變量將自動被垃圾回收，所以顯式調用該方法清除線程的局部變量並不是必須的操作，但它可以加快內存回收的速度。
protected Object initialValue()
返回該線程局部變量的初始值，該方法是一個protected的方法，顯然是為了讓子類覆蓋而設計的。這個方法是一個延遲調用方法，在線程第1次調用get()或set(Object)時才執行，並且僅執行1次。ThreadLocal中的缺省實現直接返回一個null。
值得一提的是，在JDK5.0中，ThreadLocal已經支持泛型，該類的類名已經變為ThreadLocal<T>。API方法也相應進行了調整，新版本的API方法分別是void set(T value)、T get()以及T initialValue()。
ThreadLocal是如何做到為每一個線程維護變量的副本的呢？其實實現的思路很簡單：在ThreadLocal類中有一個Map，用於存儲每一個線程的變量副本，Map中元素的鍵為線程對象，而值對應線程的變量副本。我們自己就可以提供一個簡單的實現版本：
- <span style="font-size:18px;">// 代碼清單1 SimpleThreadLocal
- class SimpleThreadLocal {
- private Map valueMap = Collections.synchronizedMap(new HashMap());
- public void set(Object newValue) {
- valueMap.put(Thread.currentThread(), newValue);// ①鍵為線程對象，值為本線程的變量副本
- }
- public Object get() {
- Thread currentThread = Thread.currentThread();
- Object o = valueMap.get(currentThread);// ②返回本線程對應的變量
- if (o == null && !valueMap.containsKey(currentThread)) {// ③如果在Map中不存在，放到Map
- // 中保存起來。
- o = initialValue();
- valueMap.put(currentThread, o);
- }
- return o;
- }
- public void remove() {
- valueMap.remove(Thread.currentThread());
- }
- public Object initialValue() {
- return null;
- }
- }</span>
雖然代碼清單9?3這個ThreadLocal實現版本顯得比較幼稚，但它和JDK所提供的ThreadLocal類在實現思路上是相近的。
一個TheadLocal實例
- <span style="font-size:18px;">package threadLocalDemo;
- public class SequenceNumber {
- // ①通過匿名內部類覆蓋ThreadLocal的initialValue()方法，指定初始值
- private static ThreadLocal<Integer> seqNum = new ThreadLocal<Integer>() {
- public Integer initialValue() {
- return 0;
- }
- };
- // ②獲取下一個序列值
- public int getNextNum() {
- seqNum.set(seqNum.get() + 1);
- return seqNum.get();
- }
- public static void main(String[] args)
- {
- SequenceNumber sn = new SequenceNumber();
- // ③ 3個線程共享sn，各自產生序列號
- TestClient t1 = new TestClient(sn);
- TestClient t2 = new TestClient(sn);
- TestClient t3 = new TestClient(sn);
- t1.start();
- t2.start();
- t3.start();
- }
- private static class TestClient extends Thread
- {
- private SequenceNumber sn;
- public TestClient(SequenceNumber sn) {
- this.sn = sn;
- }
- public void run()
- {
- for (int i = 0; i < 3; i++) {
- // ④每個線程打出3個序列值
- System.out.println("thread[" + Thread.currentThread().getName()+"] sn[" + sn.getNextNum() + "]");
- }
- }
- }
- }</span>
- http://www.xuebuyuan.com/1628079.html
- http://blog.sina.com.cn/s/blog_5204918b0100d044.html