曹工談併發：Synchronized升級為重量級鎖後，靠什麼 API 來阻塞自己
阿新 • • 發佈：2020-05-03
# 背景
因為想知道java中的關鍵字，對應的作業系統級別的api是啥，本來打算整理幾個我知道的出來，但是，尷尬的是，我發現java裡最重要的synchronized關鍵字，我就不知道它對應的api是什麼。
#redis中如何獲取鎖
在redis原始碼裡，執行緒如果要進入一個同步區（只能單執行緒進入的程式碼塊），會先獲取一個互斥量，如果獲取到了，則可以執行；否則，會阻塞在在這個互斥量上。
##互斥量型別定義：
```c
// 定義互斥量
static pthread_mutex_t bio_mutex[REDIS_BIO_NUM_OPS];
```
型別為 pthread_mutex_t。
## 互斥量初始化：
使用互斥量前，要先初始化後，才能使用：
```c
int pthread_mutex_init(pthread_mutex_t *restrict mutex,
const pthread_mutexattr_t *restrict attr);
```
pthread_mutex_init 這個函式是作業系統提供出來的api，不過應該是類unix系統才有這個。
shell中執行man pthread_mutex_init，可以看到：
```shell
The pthread_mutex_init() function shall initialize the mutex referenced by mutex with attributes specified by attr. If attr is NULL, the default mutex
attributes are used; the effect shall be the same as passing the address of a default mutex attributes object. Upon successful initialization, the state of
the mutex becomes initialized and unlocked.
```
>pthread_mutex_init 初始化引數mutex指定的互斥量，，使用attr中指定的屬性。如果attr為空，使用預設引數。
>
>成功初始化後，互斥量的狀態變為已初始化、未鎖定。
##如何鎖定、解鎖互斥量
```c
// 1
pthread_mutex_lock(&bio_mutex[type]);
// 2
pthread_mutex_unlock(&bio_mutex[type]);
```
* 1處，加鎖
* 2處，解鎖
我們可以看下linux下執行man pthread_mutex_lock後，看到的幫助：
```shell
#include
int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_trylock(pthread_mutex_t *mutex);
int pthread_mutex_unlock(pthread_mutex_t *mutex);
The mutex object referenced by mutex shall be locked by calling pthread_mutex_lock(). If the mutex is already locked, the calling thread shall block until the mutex becomes available. This operation shall return with the mutex object referenced by mutex in the locked state with the calling thread as its owner.
```
可以重點看下上面那句註釋：呼叫pthread_mutex_lock，會導致引數mutext引用的互斥量被鎖定；如果該互斥量早已被鎖定，則呼叫執行緒將被阻塞。
## redis中執行緒使用互斥量的例子
```c
void bioCreateBackgroundJob(int type, void *arg1, void *arg2, void *arg3) {
struct bio_job *job = zmalloc(sizeof(*job));
job->time = time(NULL);
job->arg1 = arg1;
job->arg2 = arg2;
job->arg3 = arg3;
// 1 鎖定
pthread_mutex_lock(&bio_mutex[type]);
// 將新工作推入佇列
listAddNodeTail(bio_jobs[type],job);
bio_pending[type]++;
pthread_cond_signal(&bio_condvar[type]);
// 2 解鎖
pthread_mutex_unlock(&bio_mutex[type]);
}
```
如要了解更多互斥量，可以看看這篇文章，寫的不錯：
[Linux C 程式設計——多執行緒和互斥鎖mutex](http://www.broadview.com.cn/article/297)
# jdk中synchronized，不考慮輕鎖、偏向鎖，最終有用到前面的互斥量嗎
## 參考文章
現在不用考慮各種優化，只考慮最終synchronized已經升級為重量級鎖之後的表現，會使用前面的互斥量嗎？
由於作者本身也是半桶水，搞了半天也沒把jdk的原始碼除錯環境搞起來，只能看看程式碼了，順便結合網路上的一些文章，不過結論應該可靠。
大家先可以參考這兩篇文章:
[JVM:鎖實現(synchronized&JSR166)行為分析和相關原始碼](https://blog.csdn.net/luoyuyou/article/details/73741387)
[JVM原始碼分析之synchronized實現](https://www.jianshu.com/p/c5058b6fe8e5)
##簡易流程梳理
我這裡也簡單列舉一下整個過程，就從下面這裡開始：
```c++
// Fast Monitor Enter/Exit
// This the fast monitor enter. The interpreter and compiler use
// some assembly copies of this code. Make sure update those code
// if the following function is changed.
// The implementation is extremely sensitive to race condition. Be careful.
void ObjectSynchronizer::fast_enter(Handle obj, BasicLock* lock, bool attempt_rebias, TRAPS) {
if (UseBiasedLocking) {
if (!SafepointSynchronize::is_at_safepoint()) {
BiasedLocking::Condition cond = BiasedLocking::revoke_and_rebias(obj, attempt_rebias, THREAD);
if (cond == BiasedLocking::BIAS_REVOKED_AND_REBIASED) {
return;
}
} else {
assert(!attempt_rebias, "can not rebias toward VM thread");
BiasedLocking::revoke_at_safepoint(obj);
}
assert(!obj->mark()->has_bias_pattern(), "biases should be revoked by now");
}
// 1
slow_enter (obj, lock, THREAD) ;
}
```
1處，前面都是偏向鎖相關的東西，先跳過，進入slow_enter。
```c++
void ObjectSynchronizer::slow_enter(Handle obj, BasicLock* lock, TRAPS) {
markOop mark = obj->mark();
assert(!mark->has_bias_pattern(), "should not see bias pattern here");
// 1
if (mark->is_neutral()) {
// Anticipate successful CAS -- the ST of the displaced mark must
// be visible <= the ST performed by the CAS.
// 2
lock-> {
private:
double CachePad [4] ; // increase odds that _mutex is sole occupant of cache line
volatile int _Event ;
volatile int _nParked ;
// 1
pthread_mutex_t _mutex [1] ;
pthread_cond_t _cond [1] ;
double PostPad [2] ;
Thread * _Assoc ;
public: // TODO-FIXME: make dtor private
~PlatformEvent() { guarantee (0, "invariant") ; }
public:
PlatformEvent() {
int status;
status = pthread_cond_init (_cond, os::Linux::condAttr());
assert_status(status == 0, status, "cond_init");
status = pthread_mutex_init (_mutex, NULL);
assert_status(status == 0, status, "mutex_init");
_Event = 0 ;
_nParked = 0 ;
_Assoc = NULL ;
}
// Use caution with reset() and fired() -- they may require MEMBARs
void reset() { _Event = 0 ; }
int fired() { return _Event; }
void park () ;
void unpark () ;
int TryPark () ;
int park (jlong millis) ; // relative timed-wait only
void SetAssociation (Thread * a) { _Assoc = a ; }
} ;
```
看到1處了嗎，原來，阻塞自己還是用了pthread_mutex_t啊。
看看park怎麼實現的:
```c++
void os::PlatformEvent::park() { // AKA "down()"
// Invariant: Only the thread associated with the Event/PlatformEvent
// may call park().
// TODO: assert that _Assoc != NULL or _Assoc == Self
int v ;
for (;;) {
v = _Event ;
if (Atomic::cmpxchg (v-1, &_Event, v) == v) break ;
}
guarantee (v >= 0, "invariant") ;
if (v == 0) {
//1 Do this the hard way by blocking ...
int status = pthread_mutex_lock(_mutex);
assert_status(status == 0, status, "mutex_lock");
guarantee (_nParked == 0, "invariant") ;
++ _nParked ;
while (_Event < 0) {
status = pthread_cond_wait(_cond, _mutex);
// for some reason, under 2.7 lwp_cond_wait() may return ETIME ...
// Treat this the same as if the wait was interrupted
if (status == ETIME) { status = EINTR; }
assert_status(status == 0 || status == EINTR, status, "cond_wait");
}
-- _nParked ;
_Event = 0 ;
// 2
status = pthread_mutex_unlock(_mutex);
...
}
guarantee (_Event >= 0, "invariant") ;
}
```
1處，加鎖；
2處，解鎖。
所以，我們本文的答案找到了。
看看其他平臺下呢？
其他平臺就不一一截圖了，除了windows，都是用的pthread_mutex_lock。
# 總結
為了這個答案，花了一天時間，值得嗎，有點不值得，時間花太長了，不過也值得，至少問題解決了。
不過，沒把除錯環境搭起來太慘了，各種標頭檔案找不到，跳轉都點不動，基本上都是全文搜尋。。。
謝謝