Java多線程之鎖學習(增強版)
阻塞鎖
含義:多個線程同時調(diào)用一個方法的時候,所有的線程都被排隊處理了,讓線程進入阻塞狀態(tài)進行等待,當獲得相應的信號(喚醒、時間)時,才能進入線程的準備就緒的狀態(tài)。通過競爭。進入運行狀態(tài)。
Java中,能夠進入\退出、阻塞狀態(tài)或包含阻塞鎖的方法有 ,synchronized 關(guān)鍵字(其中的重量鎖),ReentrantLock,Object.wait()\notify()
實例代碼如下
// 在main方法中,開啟100個線程執(zhí)行 lock() 方法
// 開啟10個線程執(zhí)行 unlock() 方法
// 此時進行加鎖和解鎖之后,加鎖多于解鎖的時候,就會一直阻塞等待
public class Demo01 {
private boolean isLocked = false;
public synchronized void lock() throws InterruptedException {
while (isLocked) {
// 當其他線程進來,即處于等待阻塞狀態(tài)
wait();
}
System.out.println("Demo01.lock");
isLocked = true;
}
public synchronized void unlock() {
isLocked = false;
System.out.println("Demo01.unlock");
notify();
}
public static void main(String[] args) {
Demo01 demo01 = new Demo01();
for (int i = 0; i < 100; i++) {
new Thread(() -> {
try {
demo01.lock();
} catch (InterruptedException e) {
e.printStackTrace();
}
}).start();
}
for (int i = 0; i < 10; i++) {
new Thread(() -> {
demo01.unlock();
}).start();
}
}
}由于被調(diào)用的方法越耗時,線程越多的時候,等待的線程等待的時間也就越長,甚至于幾分鐘或者幾十分鐘。對于Web等對反應時間要求很高的系統(tǒng)來說,這是不可行的,因此需要讓其非阻塞,可以在沒有拿到鎖之后馬上返回,告訴客戶稍后重試。
非阻塞鎖
含義:多個線程同時調(diào)用一個方法的時候,當某一個線程最先獲取到鎖,這時其他線程沒拿到鎖,這時就直接返回,只有當最先獲取的鎖的線程釋放鎖,其他線程的鎖才能進來,在它釋放之前其他線程都會獲取失敗
代碼實現(xiàn)如下
// 非阻塞鎖
public class Demo02 {
private boolean isLocked = false;
public synchronized boolean lock() throws InterruptedException {
if (isLocked) {
return false;
}
System.out.println("Demo01.lock");
isLocked = true;
return true;
}
public synchronized boolean unlock() {
if (isLocked) {
System.out.println("Demo01.unlock");
isLocked = !isLocked;
return true;
}
return false;
}
public static void main(String[] args) {
Demo02 demo01 = new Demo02();
for (int i = 0; i < 100; i++) {
new Thread(() -> {
try {
if (demo01.lock()) {
System.out.println("獲取鎖失敗");
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}).start();
}
for (int i = 0; i < 1000; i++) {
new Thread(() -> {
if (demo01.unlock()) {
System.out.println("解鎖成功");
}
}).start();
}
}
}鎖的四種狀態(tài)


鎖的狀態(tài)總共有四種:無鎖狀態(tài)、偏向鎖、輕量級鎖和重量級鎖。隨著鎖的競爭,鎖可以從偏向鎖升級到輕量級鎖,再升級的重量級鎖(但是鎖的升級是單向的,也就是說只能從低到高升級,不會出現(xiàn)鎖的降級)JDK 1.6中默認是開啟偏向鎖和輕量級鎖的,
注意:HotSpot JVM是支持鎖降級的 但是因為降級的效率太低了,所以在開發(fā)中不使用降級的操作
但是鎖的狀態(tài)時存在哪里的呢?
鎖存在Java的對象頭中的Mark Work。Mark Work默認不僅存放著鎖標志位,還存放對象hashCode等信息。運行時,會根據(jù)鎖的狀態(tài),修改Mark Work的存儲內(nèi)容。如果對象是數(shù)組類型,則虛擬機用3個字寬存儲對象頭,如果對象是非數(shù)組類型,則用2字寬存儲對象頭。在32位虛擬機中,一字寬等于四字節(jié),即32bit。
字寬(Word): 內(nèi)存大小的單位概念, 對于 32 位處理器 1 Word = 4 Bytes, 64 位處理器 1 Word = 8 Bytes
每一個 Java 對象都至少占用 2 個字寬的內(nèi)存(數(shù)組類型占用3個字寬)。
- 第一個字寬也被稱為對象頭Mark Word。 對象頭包含了多種不同的信息, 其中就包含對象鎖相關(guān)的信息。
- 第二個字寬是指向定義該對象類信息(class metadata)的指針

無鎖狀態(tài)
在代碼剛剛進入同步塊的時候,就處于無鎖狀態(tài)。
偏向鎖
概念:偏向鎖會偏向于第一個訪問鎖的線程,如果在接下來的運行過程中,該鎖沒有被其他的線程訪問,則持有偏向鎖的線程將永遠不需要觸發(fā)同步。也就是說,偏向鎖在資源無競爭的情況下消除了同步語句,連CAS操作都不做了,提高了程序的運行性能
引入偏向鎖是為了在無多線程競爭的情況下盡量減少不必要的輕量鎖執(zhí)行路徑。因為輕量級鎖的獲取以及釋放依賴多次CAS原子指令,而偏向鎖只需要在置換ThreadID的時候依賴一次原子指令(由于一旦出現(xiàn)多線程競爭的情況就必須撤銷偏向鎖,所以偏向鎖的撤銷操作的性能損耗必須小于節(jié)省下來的CAS原子指令的性能消耗)上面說過,輕量級鎖是為了在多線程交替執(zhí)行同步塊時提高性能,而偏向鎖則是在只有一個線程執(zhí)行同步塊的時候進一步提高性能。
輕量級鎖
“輕量級”是相對于使用操作系統(tǒng)互斥量來實現(xiàn)傳統(tǒng)鎖而言的。但是首先需要強調(diào)一點的是,輕量級鎖并不是用來代替重量級鎖的,它的本意是在沒有多線程競爭的前提下,減少傳統(tǒng)的重量級鎖使用產(chǎn)生的性能消耗。
在解釋輕量級鎖的執(zhí)行過程過程之前,我們要先明白一點,輕量級鎖使用的場景是線程交替同步塊的情況,如果存在同一時間訪問同一鎖的情況,就會導致輕量級鎖膨脹為重量級。
重量級鎖
synchronized是通過對象內(nèi)部的一個監(jiān)視器鎖(monitor)實現(xiàn)的。但是monitor底層又依賴于底層操作系統(tǒng)的Mutex Lock實現(xiàn)的。而操作系統(tǒng)實現(xiàn)線程之間的切換就需要從用戶態(tài)切換到核心態(tài),切換的成本很高,狀態(tài)之間的轉(zhuǎn)化需要相對比較長的時間,這就是synchronized效率低的原因,因此,這種依賴于操作系統(tǒng)的Mutex Lock所實現(xiàn)的鎖被稱之為“重量級鎖”
可重入鎖
可重入鎖也叫做遞歸鎖,指的是同一線程外層函數(shù)獲得鎖之后,內(nèi)存遞歸函數(shù)仍然有獲得該鎖的代碼,但是不受影響
Java中ReentrantLock和synchronized都是可重入鎖 自旋鎖不是可重入鎖
可重入鎖的最大作用就是避免死鎖
下面是一段實例代碼
public class Test implements Runnable {
public synchronized void get() {
System.out.println(Thread.currentThread().getId());
set();
}
public synchronized void set() {
System.out.println(Thread.currentThread().getId());
}
@Override
public void run() {
get();
}
public static void main(String[] args) {
Test ss = new Test();
new Thread(ss).start();
new Thread(ss).start();
new Thread(ss).start();
}
}
// 執(zhí)行結(jié)果
// 11
// 11
// 12
// 12
// 13
// 13
public class Test2 implements Runnable {
ReentrantLock lock = new ReentrantLock();
public void get() {
lock.lock();
try {
System.out.println(Thread.currentThread().getId());
set();
} catch (Exception e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
public void set() {
lock.lock();
try {
System.out.println(Thread.currentThread().getId());
} catch (Exception e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
@Override
public void run() {
get();
}
public static void main(String[] args) {
Test ss = new Test();
new Thread(ss).start();
new Thread(ss).start();
new Thread(ss).start();
}
}
// 執(zhí)行結(jié)果
// 11
// 11
// 12
// 12
// 13
// 13
自旋鎖
public class SpinLock {
private AtomicReference<Thread> owner = new AtomicReference<>();
public void lock() {
Thread current = Thread.currentThread();
while (!owner.compareAndSet(null, current)) {
}
}
public void unlock() {
Thread current = Thread.currentThread();
owner.compareAndSet(current, null);
}
改進的自旋鎖
public class SpinLock1 {
private AtomicReference<Thread> owner =new AtomicReference<>();
private int count =0;
public void lock(){
Thread current = Thread.currentThread();
if(current==owner.get()) {
count++;
return ;
}
while(!owner.compareAndSet(null, current)){
}
}
public void unlock (){
Thread current = Thread.currentThread();
if(current==owner.get()){
if(count!=0){
count--;
}else{
owner.compareAndSet(current, null);
}
}
}
}讀寫鎖
Lock接口以及其對象,使用它,很優(yōu)雅的控制了競爭資源的安全訪問,但是這種鎖不區(qū)別讀寫 - 為普通鎖
為了提高性能,Java提供了讀寫鎖,在讀的地方使用讀鎖,在寫的時候使用寫鎖,靈活控制,如果沒有寫鎖的情況下。讀是無阻塞的,在一定情況下提高了程序的執(zhí)行效率。下面我們來看源代碼(Lock接口和Condition接口在上一篇Java - 多線程 - 鎖和提升 第1篇已經(jīng)分析過,此處不再分析)
public class ReentrantReadWriteLock
implements ReadWriteLock, java.io.Serializable {
private static final long serialVersionUID = -6992448646407690164L;
// 讀鎖內(nèi)部類對象
private final ReentrantReadWriteLock.ReadLock readerLock;
// 寫鎖內(nèi)部類對象
private final ReentrantReadWriteLock.WriteLock writerLock;
// 執(zhí)行所有的同步機制
final Sync sync;
// 無參構(gòu)造函數(shù) 調(diào)用有參構(gòu)造 ReentrantReadWriteLock(boolean fair)
public ReentrantReadWriteLock() {
this(false);
}
// 有參構(gòu)造函數(shù) 是否創(chuàng)建公平鎖
public ReentrantReadWriteLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
readerLock = new ReadLock(this);
writerLock = new WriteLock(this);
}
// 返回讀鎖和寫鎖的對象
public ReentrantReadWriteLock.WriteLock writeLock() { return writerLock; }
public ReentrantReadWriteLock.ReadLock readLock() { return readerLock; }
// 繼承自 AbstractQueueSynchronizer 的Sync
abstract static class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = 6317671515068378041L;
// 共享移位
static final int SHARED_SHIFT = 16;
// 共享單位
static final int SHARED_UNIT = (1 << SHARED_SHIFT);
// 最大數(shù)量
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;
// 獨占
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
// 返回共享鎖的數(shù)量
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
// 返回獨占鎖的數(shù)量
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
// 每線程讀取保持計數(shù)的計數(shù)器
static final class HoldCounter {
int count = 0;
// 使用id 而不是使用引用 避免垃圾殘留
final long tid = getThreadId(Thread.currentThread());
}
// 線程本地子類
static final class ThreadLocalHoldCounter
extends ThreadLocal<HoldCounter> {
public HoldCounter initialValue() {
return new HoldCounter();
}
}
// 當前線程持有的可重入鎖的數(shù)量,只在構(gòu)造函數(shù)和readObject中初始化,
// 當線程的讀取保持計數(shù)下降到0的時候刪除
private transient ThreadLocalHoldCounter readHolds;
// 獲取readLock的最后一個線程的保持計數(shù)
private transient HoldCounter cachedHoldCounter;
// 第一個獲得讀的線程
private transient Thread firstReader = null;
// 計數(shù)器
private transient int firstReaderHoldCount;
Sync() {
readHolds = new ThreadLocalHoldCounter();
setState(getState()); // ensures visibility of readHolds
}
// 當前線程獲取鎖的時候由于策略超過其他等待線程而應阻止,返回true
abstract boolean readerShouldBlock();
// 如果由于試圖超越其他等待線程的策略而導致當前線程在嘗試獲取寫鎖(且有資格這樣做)
// 時應阻塞,則返回true
abstract boolean writerShouldBlock();
// 嘗試釋放
protected final boolean tryRelease(int releases) {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
int nextc = getState() - releases;
boolean free = exclusiveCount(nextc) == 0;
if (free)
setExclusiveOwnerThread(null);
setState(nextc);
return free;
}
// 嘗試增加
protected final boolean tryAcquire(int acquires) {
/*
* Walkthrough:
* 1. If read count nonzero or write count nonzero
* and owner is a different thread, fail.
* 2. If count would saturate, fail. (This can only
* happen if count is already nonzero.)
* 3. Otherwise, this thread is eligible for lock if
* it is either a reentrant acquire or
* queue policy allows it. If so, update state
* and set owner.
*/
Thread current = Thread.currentThread();
int c = getState();
int w = exclusiveCount(c);
if (c != 0) {
// (Note: if c != 0 and w == 0 then shared count != 0)
if (w == 0 || current != getExclusiveOwnerThread())
return false;
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// Reentrant acquire
setState(c + acquires);
return true;
}
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
setExclusiveOwnerThread(current);
return true;
}
// 嘗試釋放共享鎖
protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread();
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1)
firstReader = null;
else
firstReaderHoldCount--;
} else {
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
int count = rh.count;
if (count <= 1) {
readHolds.remove();
if (count <= 0)
throw unmatchedUnlockException();
}
--rh.count;
}
for (;;) {
int c = getState();
int nextc = c - SHARED_UNIT;
if (compareAndSetState(c, nextc))
// Releasing the read lock has no effect on readers,
// but it may allow waiting writers to proceed if
// both read and write locks are now free.
return nextc == 0;
}
}
// 非法的監(jiān)視器狀態(tài)異常
private IllegalMonitorStateException unmatchedUnlockException() {
return new IllegalMonitorStateException(
"attempt to unlock read lock, not locked by current thread");
}
// 嘗試加共享鎖
protected final int tryAcquireShared(int unused) {
/*
* Walkthrough:
* 1. If write lock held by another thread, fail.
* 2. Otherwise, this thread is eligible for
* lock wrt state, so ask if it should block
* because of queue policy. If not, try
* to grant by CASing state and updating count.
* Note that step does not check for reentrant
* acquires, which is postponed to full version
* to avoid having to check hold count in
* the more typical non-reentrant case.
* 3. If step 2 fails either because thread
* apparently not eligible or CAS fails or count
* saturated, chain to version with full retry loop.
*/
Thread current = Thread.currentThread();
int c = getState();
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return -1;
int r = sharedCount(c);
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) {
if (r == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
}
return 1;
}
return fullTryAcquireShared(current);
}
// 讀取的完整版本,可處理CAS丟失和tryAcquireShared中未處理的可重入讀取
final int fullTryAcquireShared(Thread current) {
HoldCounter rh = null;
for (;;) {
int c = getState();
if (exclusiveCount(c) != 0) {
if (getExclusiveOwnerThread() != current)
return -1;
} else if (readerShouldBlock()) {
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
} else {
if (rh == null) {
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) {
rh = readHolds.get();
if (rh.count == 0)
readHolds.remove();
}
}
if (rh.count == 0)
return -1;
}
}
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (sharedCount(c) == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}
// 執(zhí)行tryLock進行寫入,從而在兩種模式下都可以進行插入,這與tryAcquire的作用相同
// 只是缺少對 writerShouldBlock的調(diào)用
final boolean tryWriteLock() {
Thread current = Thread.currentThread();
int c = getState();
if (c != 0) {
int w = exclusiveCount(c);
if (w == 0 || current != getExclusiveOwnerThread())
return false;
if (w == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
}
if (!compareAndSetState(c, c + 1))
return false;
setExclusiveOwnerThread(current);
return true;
}
// 執(zhí)行tryLock進行讀取,從而在兩種模式下都可以進行插入。
// 除了沒有調(diào)用readerReaderShouldBlock以外,這與tryAcquireShared的作用相同。
final boolean tryReadLock() {
Thread current = Thread.currentThread();
for (;;) {
int c = getState();
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return false;
int r = sharedCount(c);
if (r == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (r == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
}
return true;
}
}
}
// 是否獨占鎖
protected final boolean isHeldExclusively() {
return getExclusiveOwnerThread() == Thread.currentThread();
}
// 返回Condition對象
final ConditionObject newCondition() {
return new ConditionObject();
}
// 返回獨占鎖
final Thread getOwner() {
return ((exclusiveCount(getState()) == 0) ?
null :
getExclusiveOwnerThread());
}
// 獲取readLock所得個數(shù)
final int getReadLockCount() {
return sharedCount(getState());
}
// 判斷是否是 writeLock 鎖
final boolean isWriteLocked() {
return exclusiveCount(getState()) != 0;
}
// 獲得寫鎖的數(shù)量
final int getWriteHoldCount() {
return isHeldExclusively() ? exclusiveCount(getState()) : 0;
}
// 獲得讀鎖的數(shù)量
final int getReadHoldCount() {
if (getReadLockCount() == 0)
return 0;
Thread current = Thread.currentThread();
if (firstReader == current)
return firstReaderHoldCount;
HoldCounter rh = cachedHoldCounter;
if (rh != null && rh.tid == getThreadId(current))
return rh.count;
int count = readHolds.get().count;
if (count == 0) readHolds.remove();
return count;
}
// 序列化
private void readObject(java.io.ObjectInputStream s)
throws java.io.IOException, ClassNotFoundException {
s.defaultReadObject();
readHolds = new ThreadLocalHoldCounter();
setState(0); // reset to unlocked state
}
// 獲取數(shù)量
final int getCount() { return getState(); }
}
// 非公平鎖
static final class NonfairSync extends Sync {
private static final long serialVersionUID = -8159625535654395037L;
final boolean writerShouldBlock() {
return false; // writers can always barge
}
final boolean readerShouldBlock() {
return apparentlyFirstQueuedIsExclusive();
}
}
// 公平鎖
static final class FairSync extends Sync {
private static final long serialVersionUID = -2274990926593161451L;
final boolean writerShouldBlock() {
return hasQueuedPredecessors();
}
final boolean readerShouldBlock() {
return hasQueuedPredecessors();
}
}
// 讀鎖實現(xiàn)了 Lock 接口
public static class ReadLock implements Lock, java.io.Serializable {
private static final long serialVersionUID = -5992448646407690164L;
private final Sync sync;
// 初始化,獲得是否是公平讀鎖
protected ReadLock(ReentrantReadWriteLock lock) {
sync = lock.sync;
}
// 加鎖 是共享鎖
public void lock() {
sync.acquireShared(1);
}
// 鎖中斷
public void lockInterruptibly() throws InterruptedException {
sync.acquireSharedInterruptibly(1);
}
// 調(diào)用加鎖
public boolean tryLock() {
return sync.tryReadLock();
}
// 超時加鎖
public boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException {
return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout));
}
// 解鎖
public void unlock() {
sync.releaseShared(1);
}
// Condition 對象
public Condition newCondition() {
throw new UnsupportedOperationException();
}
// toString方法
public String toString() {
int r = sync.getReadLockCount();
return super.toString() +
"[Read locks = " + r + "]";
}
}
// 寫鎖
public static class WriteLock implements Lock, java.io.Serializable {
private static final long serialVersionUID = -4992448646407690164L;
private final Sync sync;
// 寫鎖初始化
protected WriteLock(ReentrantReadWriteLock lock) {
sync = lock.sync;
}
// 加鎖
public void lock() {
sync.acquire(1);
}
// 鎖中斷
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
// 加鎖
public boolean tryLock( ) {
return sync.tryWriteLock();
}
// 超時加鎖
public boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException {
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}
// 解鎖,調(diào)用 release 減1
public void unlock() {
sync.release(1);
}
// Condition對象
public Condition newCondition() {
return sync.newCondition();
}
// toString方法
public String toString() {
Thread o = sync.getOwner();
return super.toString() + ((o == null) ?
"[Unlocked]" :
"[Locked by thread " + o.getName() + "]");
}
// 是否有獨占的線程
public boolean isHeldByCurrentThread() {
return sync.isHeldExclusively();
}
// 獲取寫鎖的數(shù)量
public int getHoldCount() {
return sync.getWriteHoldCount();
}
}
// 判斷是否是公平鎖
public final boolean isFair() {
return sync instanceof FairSync;
}
// 判斷是否是獨占鎖
protected Thread getOwner() {
return sync.getOwner();
}
// 獲取讀鎖的個數(shù)
public int getReadLockCount() {
return sync.getReadLockCount();
}
// 判斷是否是寫鎖
public boolean isWriteLocked() {
return sync.isWriteLocked();
}
// 判斷鎖是否被當前線程持有
public boolean isWriteLockedByCurrentThread() {
return sync.isHeldExclusively();
}
// 查詢當前線程對該鎖的可重入寫入次數(shù)
public int getWriteHoldCount() {
return sync.getWriteHoldCount();
}
// 查詢當前線程對該鎖的可重讀次數(shù)
public int getReadHoldCount() {
return sync.getReadHoldCount();
}
// 返回寫線程的集合
protected Collection<Thread> getQueuedWriterThreads() {
return sync.getExclusiveQueuedThreads();
}
// 返回讀線程的集合
protected Collection<Thread> getQueuedReaderThreads() {
return sync.getSharedQueuedThreads();
}
// 查詢是否有任何線程正在等待獲取讀或?qū)戞i
public final boolean hasQueuedThreads() {
return sync.hasQueuedThreads();
}
// 查詢指定線程是否在等待讀或者寫鎖
public final boolean hasQueuedThread(Thread thread) {
return sync.isQueued(thread);
}
// 獲取等待隊列的長度
public final int getQueueLength() {
return sync.getQueueLength();
}
// 獲得等待隊列中的線程集合
protected Collection<Thread> getQueuedThreads() {
return sync.getQueuedThreads();
}
// 查詢是否有任何線程正在等待與寫鎖關(guān)聯(lián)的給定條件
public boolean hasWaiters(Condition condition) {
if (condition == null)
throw new NullPointerException();
if (!(condition instanceof AbstractQueuedSynchronizer.ConditionObject))
throw new IllegalArgumentException("not owner");
return sync.hasWaiters((AbstractQueuedSynchronizer.ConditionObject)condition);
}
// 查詢是否有任何線程正在等待與寫鎖關(guān)聯(lián)的給定條件的長度
public int getWaitQueueLength(Condition condition) {
if (condition == null)
throw new NullPointerException();
if (!(condition instanceof AbstractQueuedSynchronizer.ConditionObject))
throw new IllegalArgumentException("not owner");
return sync.getWaitQueueLength((AbstractQueuedSynchronizer.ConditionObject)condition);
}
// 獲得給定條件等待線程的集合
protected Collection<Thread> getWaitingThreads(Condition condition) {
if (condition == null)
throw new NullPointerException();
if (!(condition instanceof AbstractQueuedSynchronizer.ConditionObject))
throw new IllegalArgumentException("not owner");
return sync.getWaitingThreads((AbstractQueuedSynchronizer.ConditionObject)condition);
}
// toString()方法
public String toString() {
int c = sync.getCount();
int w = Sync.exclusiveCount(c);
int r = Sync.sharedCount(c);
return super.toString() +
"[Write locks = " + w + ", Read locks = " + r + "]";
}
// 獲取線程ID
static final long getThreadId(Thread thread) {
return UNSAFE.getLongVolatile(thread, TID_OFFSET);
}
// Unsafe對象
private static final sun.misc.Unsafe UNSAFE;
private static final long TID_OFFSET;
static {
try {
UNSAFE = sun.misc.Unsafe.getUnsafe();
Class<?> tk = Thread.class;
TID_OFFSET = UNSAFE.objectFieldOffset
(tk.getDeclaredField("tid"));
} catch (Exception e) {
throw new Error(e);
}
}
}
總結(jié):
- 從讀寫鎖的實現(xiàn)代碼,我們可以看到,其本質(zhì)還是使用了AQS的獨占鎖和共享鎖實現(xiàn)了讀寫分離。
- 當需要進行讀的時候使用共享鎖,當需要寫的時候使用獨占鎖
- 同時,ReentrantReadWriteLock也提供了默認的非公平機制,當然也可以使用構(gòu)造方法設(shè)置是否是公平鎖
互斥鎖
互斥鎖指的是一次最多只能有一個線程持有的鎖。如Java的Lock
互斥鎖也是為了保護共享資源的同步,在任何時刻,最多只能有一個保持者,也就說,在任何時刻最多只能有一個執(zhí)行單元獲得鎖?;コ怄i和自旋鎖在調(diào)度機制上略有不同。對于互斥鎖,如果資源已經(jīng)被占用,資源申請者只能進入睡眠狀態(tài)。但是自旋鎖不會引起調(diào)用者睡眠,如果自旋鎖已經(jīng)被別的執(zhí)行單元保持,調(diào)用者就一直循環(huán)在那里看是否該自旋鎖的保持者已經(jīng)釋放了鎖。
悲觀鎖
悲觀鎖,顧名思義就是狠悲觀,認為每次拿去的數(shù)據(jù)都會被修改,所以在每次拿鎖的時候都會上鎖,這樣別人想拿到這個數(shù)據(jù)就會block到直到他拿到鎖。傳統(tǒng)的數(shù)據(jù)庫就使用了很多的這種的機制:如行鎖、表鎖、讀鎖、寫鎖等,都是在做操作之前上鎖。共享鎖、排他鎖、獨占鎖是悲觀鎖的一種實現(xiàn)。
Java中的悲觀鎖,最典型的就是synchronized。而AQS框架下的鎖,先嘗試使用CAS樂觀鎖去獲取鎖,獲取不到才會轉(zhuǎn)為悲觀鎖,如ReentrantLock
樂觀鎖
樂觀鎖,顧名思義就是很樂觀,每次拿去的數(shù)據(jù)都認為不會被修改,所以不會上鎖。但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數(shù)據(jù),對于此過程出現(xiàn)的ABA問題,可以使用版本號進行控制。
樂觀鎖用于多讀的場景,數(shù)據(jù)庫提供的類似于write_condition機制都是使用了樂觀鎖,使用CAS保證這個操作的原子性
樂觀鎖和悲觀鎖的比較
- 樂觀鎖不是數(shù)據(jù)庫自己實現(xiàn)的,悲觀鎖是數(shù)據(jù)庫自己實現(xiàn)的
- 兩種鎖各有優(yōu)缺點,不能認為一種好于另外一種,樂觀鎖適用于寫少的場景,也就是沖突發(fā)生很少的情況,這樣省了鎖的開銷,加大了系統(tǒng)的吞吐量。
- 但是如果經(jīng)常發(fā)生沖突,上次應用不會retry,此時為了保證安全和維持性能,應該使用悲觀鎖
公平鎖
公平鎖。就是字面意思,公平的,是非搶占式的,一個一個排好隊,等待執(zhí)行,但是有缺點。如果某個線程執(zhí)行的時間過長,會導致阻塞。比如ReentrantLock中的內(nèi)部類 FairSync和ReentrantReadWriteLock中的內(nèi)部類FairSync都是公平鎖
非公平鎖
非公平鎖,及時字面以自,搶占式的,不管誰先來,誰后來,搶到了就是我的。比如ReentrantLock中的內(nèi)部類 NonfairSync和ReentrantReadWriteLock中的內(nèi)部類NonfairSync都是非公平鎖
顯示鎖和內(nèi)置鎖
顯示鎖,是人為手動的鎖,如:ReentrantLock、Lock鎖,也就是說,實現(xiàn)了Lock的鎖都是顯示鎖
內(nèi)置鎖:內(nèi)置鎖使用synchronized,內(nèi)置鎖是互斥鎖
Java中每個對象都可以用作一個實現(xiàn)同步的鎖。 線程進入同步代碼塊或方法的時候會自動獲得該鎖,在退出同步代碼塊或方法時會釋放該鎖。獲得內(nèi)置鎖的唯一途徑就是進入這個鎖的保護的同步代碼塊或方法。
輪詢鎖和定時鎖
由tryLock實現(xiàn),與無條件獲取鎖模式相比,它們具有更完善的錯誤恢復機制??杀苊馑梨i的發(fā)生
boolean tryLock():僅在調(diào)用時鎖為空閑狀態(tài)才獲取該鎖。如果鎖可用,則獲取鎖,并立即返回值 true。如果鎖不可用,則此方法將立即返回值 false。
tryLock的重載 tryLock(time,TimeUnit)就是定時鎖
對象鎖和類鎖
Java的對象鎖和類鎖,其實也就是 Java - 多線程 - 鎖和提升 第1篇開篇所說的8鎖 8鎖核心思想
- 關(guān)鍵字在實例方法上,鎖為當前實例
- 關(guān)鍵字在靜態(tài)方法上,鎖為當前Class對象
- 關(guān)鍵字在代碼塊上,鎖為括號里面的對象
1.對象鎖和類鎖在基本概念上和內(nèi)置鎖是一致的,但是,兩個鎖是有很大的區(qū)別,對象鎖適用于對象的實例方法,或者一個對象實例上的,類鎖是作用于類的靜態(tài)方法或者一個類的class對象上的。
2.類的實例可以有多個,但是每個類只有一個class對象,不同實例的對象鎖是互不相干的,但是每個類只有一個類鎖。
3.其實類鎖只是一個概念上的東西,并不是真實存在的,它只是用來幫我們理解鎖定實例方法和靜態(tài)方法的區(qū)別。
4.synchronized只是一個內(nèi)置的加鎖機制,當某個方法加上synchronized關(guān)鍵字的后,就表明要獲得該內(nèi)置鎖才能執(zhí)行,并不能阻止其他線程訪問不需要獲得該鎖的方法。
5.調(diào)用對象的wait()方法的時候,會釋放持有的對象鎖,以便于調(diào)用 notify() 方法使用。notify()調(diào)用之后,會等到notify()所在的線程執(zhí)行完畢之后再釋放鎖。
鎖粗化
就是將多次連接在一起的加鎖、解鎖操作合并為一次,將多個連續(xù)的鎖拓展為一個更大的鎖。
通常情況下,為了保證多線程間的有效并發(fā),會要求每個線程持有鎖的時間盡可能短,但是大某些情況下,一個程序?qū)ν粋€鎖不間斷、高頻地請求、同步與釋放,會消耗掉一定的系統(tǒng)資源,因為鎖的講求、同步與釋放本身會帶來性能損耗,這樣高頻的鎖請求就反而不利于系統(tǒng)性能的優(yōu)化了,雖然單次同步操作的時間可能很短。鎖粗化就是告訴我們?nèi)魏问虑槎加袀€度,有些情況下我們反而希望把很多次鎖的請求合并成一個請求,以降低短時間內(nèi)大量鎖請求、同步、釋放帶來的性能損耗。
鎖消除
鎖消除即:刪除不必要的加鎖操作。根據(jù)代碼逃逸技術(shù),如果判斷到一段代碼中,堆上的數(shù)據(jù)不會逃逸出當前線程。那么可以認定這段代碼是線程安全的,不必要加鎖。
鎖消除是發(fā)生在編譯器級別的一種鎖優(yōu)化方式。有時候我們寫的代碼完全不需要加鎖,卻執(zhí)行了加鎖操作。
比如,StringBuffer類的append操作:
@Override
public synchronized StringBuffer append(String str) {
toStringCache = null;
super.append(str);
return this;
}
從源碼中可以看出,append方法用了synchronized關(guān)鍵詞,它是線程安全的。但我們可能僅在線程內(nèi)部把StringBuffer當作局部變量使用:
public class Demo {
public static void main(String[] args) {
long start = System.currentTimeMillis();
int size = 10000;
for (int i = 0; i < size; i++) {
createStringBuffer("ic", "java");
}
long timeCost = System.currentTimeMillis() - start;
System.out.println("createStringBuffer:" + timeCost + " ms");
}
public static String createStringBuffer(String str1, String str2) {
StringBuffer sBuf = new StringBuffer();
// append方法是同步操作
sBuf.append(str1);
sBuf.append(str2);
return sBuf.toString();
}
}代碼中createStringBuffer方法中的局部對象sBuf,就只在該方法內(nèi)的作用域有效,不同線程同時調(diào)用createStringBuffer()方法時,都會創(chuàng)建不同的sBuf對象,因此此時的append操作若是使用同步操作,就是白白浪費的系統(tǒng)資源。
這時我們可以通過編譯器將其優(yōu)化,將鎖消除,前提是java必須運行在server模式(server模式會比client模式作更多的優(yōu)化),同時必須開啟逃逸分析:
-server -XX:+DoEscapeAnalysis -XX:+EliminateLocks
其中+DoEscapeAnalysis表示開啟逃逸分析,+EliminateLocks表示鎖消除。
逃逸分析:比如上面的代碼,它要看sBuf是否可能逃出它的作用域?如果將sBuf作為方法的返回值進行返回,那么它在方法外部可能被當作一個全局對象使用,就有可能發(fā)生線程安全問題,這時就可以說sBuf這個對象發(fā)生逃逸了,因而不應將append操作的鎖消除,但我們上面的代碼沒有發(fā)生鎖逃逸,鎖消除就可以帶來一定的性能提升。
信號量
信號量有一個線程同步工具:Semaphore
下面我們來分析一下源碼
public class Semaphore implements java.io.Serializable {
private static final long serialVersionUID = -3222578661600680210L;
// Sync鎖
private final Sync sync;
// Sync實現(xiàn)了AbstractQueueSynchronizer
abstract static class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = 1192457210091910933L;
// 初始化版本初始值
Sync(int permits) {
setState(permits);
}
// 獲取狀態(tài)
final int getPermits() {
return getState();
}
// 不公平嘗試共享
final int nonfairTryAcquireShared(int acquires) {
for (;;) {
int available = getState();
int remaining = available - acquires;
if (remaining < 0 ||
compareAndSetState(available, remaining))
return remaining;
}
}
// 嘗試釋放共享
protected final boolean tryReleaseShared(int releases) {
for (;;) {
int current = getState();
int next = current + releases;
if (next < current) // overflow
throw new Error("Maximum permit count exceeded");
if (compareAndSetState(current, next))
return true;
}
}
// 減少狀態(tài)的指定值
final void reducePermits(int reductions) {
for (;;) {
int current = getState();
int next = current - reductions;
if (next > current) // underflow
throw new Error("Permit count underflow");
if (compareAndSetState(current, next))
return;
}
}
final int drainPermits() {
for (;;) {
int current = getState();
if (current == 0 || compareAndSetState(current, 0))
return current;
}
}
}
// 非公平鎖
static final class NonfairSync extends Sync {
private static final long serialVersionUID = -2694183684443567898L;
NonfairSync(int permits) {
super(permits);
}
protected int tryAcquireShared(int acquires) {
return nonfairTryAcquireShared(acquires);
}
}
// 公平鎖
static final class FairSync extends Sync {
private static final long serialVersionUID = 2014338818796000944L;
FairSync(int permits) {
super(permits);
}
protected int tryAcquireShared(int acquires) {
for (;;) {
if (hasQueuedPredecessors())
return -1;
int available = getState();
int remaining = available - acquires;
if (remaining < 0 ||
compareAndSetState(available, remaining))
return remaining;
}
}
}
// 構(gòu)造方法 設(shè)置初始版本號
public Semaphore(int permits) {
sync = new NonfairSync(permits);
}
// 構(gòu)造方法
public Semaphore(int permits, boolean fair) {
sync = fair ? new FairSync(permits) : new NonfairSync(permits);
}
// 增加1
public void acquire() throws InterruptedException {
sync.acquireSharedInterruptibly(1);
}
// 不間斷地獲取
public void acquireUninterruptibly() {
sync.acquireShared(1);
}
// 從此信號量獲取許可,直到獲得一個許可為止,將一直阻塞
public void acquireUninterruptibly() {
sync.acquireShared(1);
}
// 僅在調(diào)用時可用時,才從此信號量獲取許可
public boolean tryAcquire() {
return sync.nonfairTryAcquireShared(1) >= 0;
}
// 定時設(shè)置
public boolean tryAcquire(long timeout, TimeUnit unit)
throws InterruptedException {
return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout));
}
// 釋放
public void release() {
sync.releaseShared(1);
}
// 設(shè)置指定的個數(shù)
public void acquire(int permits) throws InterruptedException {
if (permits < 0) throw new IllegalArgumentException();
sync.acquireSharedInterruptibly(permits);
}
// 獲得許可證的給定數(shù)目從這個信號,阻塞直到所有可用。
public void acquireUninterruptibly(int permits) {
if (permits < 0) throw new IllegalArgumentException();
sync.acquireShared(permits);
}
// 獲得許可證的給定數(shù)目從此信號量,只有在所有可在調(diào)用的時候。
public boolean tryAcquire(int permits) {
if (permits < 0) throw new IllegalArgumentException();
return sync.nonfairTryAcquireShared(permits) >= 0;
}
// 收購從此信號量許可證的給定數(shù)量,如果所有給定的等待時間內(nèi)變得可用,并且當前線程未被中斷
public boolean tryAcquire(int permits, long timeout, TimeUnit unit)
throws InterruptedException {
if (permits < 0) throw new IllegalArgumentException();
return sync.tryAcquireSharedNanos(permits, unit.toNanos(timeout));
}
// 釋放
public void release(int permits) {
if (permits < 0) throw new IllegalArgumentException();
sync.releaseShared(permits);
}
// 返回現(xiàn)在的剩余值
public int availablePermits() {
return sync.getPermits();
}
// 返回減少之后的值
public int drainPermits() {
return sync.drainPermits();
}
// 減少指定個數(shù)的值
protected void reducePermits(int reduction) {
if (reduction < 0) throw new IllegalArgumentException();
sync.reducePermits(reduction);
}
// 判斷是否時公平鎖
public boolean isFair() {
return sync instanceof FairSync;
}
// 判斷隊列是否有線程
public final boolean hasQueuedThreads() {
return sync.hasQueuedThreads();
}
// 返回線程的長度
public final int getQueueLength() {
return sync.getQueueLength();
}
// 返回隊列線程的集合
protected Collection<Thread> getQueuedThreads() {
return sync.getQueuedThreads();
}
// toString() 方法
public String toString() {
return super.toString() + "[Permits = " + sync.getPermits() + "]";
}
}
總結(jié):
我們發(fā)現(xiàn)其本質(zhì)還是 AbstractQueueSynchronizer 中的共享模式和獨占模式
此類也有公平和非公平的實現(xiàn)
獨享鎖
獨享鎖,也叫獨占鎖,意思是鎖A只能被一個鎖擁有,如synchronized,
ReentrantLock是獨享鎖,他是基于AQS實現(xiàn)的,在ReentrantLock源碼中, 使用一個int類型的成員變量state來表示同步狀態(tài),當state>0時表示已經(jīng)獲取了鎖 。 而當c等于0的時候說明當前沒有線程占有鎖,它提供了三個方法(getState()、setState(int newState)、compareAndSetState(int expect,int update))來對同步狀態(tài)state進行操作,所以AQS可以確保對state的操作是安全的。
// 它默認是非公平鎖
public ReentrantLock() {
sync = new NonfairSync();
}
// 創(chuàng)建ReentrantLock,公平鎖or非公平鎖
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
// 而他會分別調(diào)用lock方法和unlock方法來釋放鎖
public void lock() {
sync.lock();
}
public void unlock() {
sync.release(1);
}
但是其實他不僅僅是會調(diào)用lock和unlock方法,因為我們的線程不可能一點問題沒有,如果說進入到了waiting狀態(tài),在這個時候如果沒有unpark()方法,就沒有辦法來喚醒他, 所以,也就接踵而至出現(xiàn)了tryLock(),tryLock(long,TimeUnit)來做一些嘗試加鎖或者說是超時來滿足某些特定的場景的需求了
ReentrantLock會保證method-body在同一時間只有一個線程在執(zhí)行這段代碼,或者說,同一時刻只有一個線程的lock方法會返回。其余線程會被掛起,直到獲取鎖。
從這里我們就能看出,其實ReentrantLock實現(xiàn)的就是一個獨占鎖的功能:有且只有一個線程獲取到鎖,其余線程全部掛起,直到該擁有鎖的線程釋放鎖,被掛起的線程被喚醒重新開始競爭鎖。而在源碼中通過AQS來獲取獨享鎖是通過調(diào)用acquire方法,其實這個方法是阻塞的
共享鎖
從我們之前的獨享所就能看得出來,獨享鎖是使用的一個狀態(tài)來進行鎖標記的,共享鎖其實也差不多,但是JAVA中有不想定力兩個狀態(tài),所以區(qū)別出現(xiàn)了, 他們的鎖狀態(tài)時不一樣的。
基本的流程是一樣的,主要區(qū)別在于判斷鎖獲取的條件上,由于是共享鎖,也就允許多個線程同時獲取,所以同步狀態(tài)的數(shù)量同時的大于1的,如果同步狀態(tài)為非0,則線程就可以獲取鎖,只有當同步狀態(tài)為0時,才說明共享數(shù)量的鎖已經(jīng)被全部獲取,其余線程只能等待。
最典型的就是ReentrantReadWriteLock里的讀鎖,它的讀鎖是可以被共享的,但是它的寫鎖確每次只能被獨占。
總結(jié)
- 獨享鎖:同時只能有一個線程獲得鎖。
- 共享鎖:可以有多個線程同時獲得鎖。
分段鎖
在JDK1.7之前,HashMap的底層是數(shù)組+鏈表。同樣的,ConcurrentHashMap的底層樹結(jié)構(gòu)是數(shù)組+鏈表,但是和HashMap不一樣的是,ConcurrentHashMap的中存放數(shù)據(jù)是一段一段的。即由很多個Segment(段)組成的,每個Segment中都有著類似于數(shù)組+鏈表的結(jié)構(gòu)
關(guān)于Segment
1.ConcurrentHashMap由三個參數(shù)
- initalCapacity:初始化總?cè)萘?,默認值為16
- loadFactor:加載因子,默認0.75
- concurrentLevel:并發(fā)級別,默認16
2.其中的并發(fā)級別控制了Segment的個數(shù)。在y一個ConcurrentHashMap創(chuàng)建后Segment的個數(shù)是不能變的,擴容過程是改變每個Segment的大小
關(guān)于分段鎖
Segment繼承了重入鎖ReentrantLock,有了鎖的的功能。每個鎖控制的是一段,當每個Segment越來越大的時候,鎖的粒度就越來越大了
- 分段鎖的優(yōu)勢是保證造操作不同段map的時候進行鎖的競爭和等待。這相當于直接對整個map同步synchronized只是有優(yōu)勢的
- 缺點在于分成很多段的時候會浪費很多的內(nèi)存空間(不連續(xù),碎片化),操作map的時候競爭一個分段鎖概率狠小的時候,分段鎖反而會造成更新等操作的長時間等待,分段鎖的性能會下降
JDK1.8的map實現(xiàn)
JDK中的HashMap和ConcurrentHashMap。底層數(shù)據(jù)結(jié)構(gòu)為數(shù)組+鏈表+紅黑樹。數(shù)組可以擴容,鏈表可以轉(zhuǎn)化為紅黑樹(本篇文章不對紅黑樹做講解,之前已經(jīng)分析過)
新版的ConcurrentHashMap為什么不使用ReentrantLock而使用synchronized?
減少內(nèi)存開銷:如果使用ReenteantLock則需要節(jié)點繼承AQS來獲得同步支持,增加內(nèi)存開銷,而1.8中只有頭節(jié)點需要同步
內(nèi)部優(yōu)化:synchronized是JVM直接支持的,JVM能在運行時做出相應的優(yōu)化措施:鎖粗化、鎖消除、鎖自旋等
鎖的粒度
首先鎖的粒度并沒有變粗,甚至變得更細了。每當擴容一次,ConcurrentHashMap的并發(fā)度就擴大一倍。
Hash沖突
JDK1.7中,ConcurrentHashMap從過二次hash的方式(Segment -> HashEntry)能夠快速的找到查找的元素。在1.8中通過鏈表加紅黑樹的形式彌補了put、get時的性能差距。
擴容
JDK1.8中,在ConcurrentHashmap進行擴容時,其他線程可以通過檢測數(shù)組中的節(jié)點決定是否對這條鏈表(紅黑樹)進行擴容,減小了擴容的粒度,提高了擴容的效率。
死鎖案例和排查
public class DeadLockDemo {
public static void main(String[] args) {
String lockA = "lockA";
String lockB = "lockB";
MyThread myThread1 = new MyThread(lockA,lockB);
MyThread myThread2 = new MyThread(lockB,lockA);
new Thread(myThread1).start();
new Thread(myThread2).start();
}
}
class MyThread implements Runnable {
private String lockA;
private String lockB;
public MyThread(String lockA, String lockB) {
this.lockA = lockA;
this.lockB = lockB;
}
@Override
public void run() {
synchronized (lockA) {
System.out.println(Thread.currentThread().getName() + "lock:" + lockA + " => " + lockB);
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (lockB) {
System.out.println(Thread.currentThread().getName() + "lock:" + lockB + " => " + lockA);
}
}
}
}
到此這篇關(guān)于Java多線程之鎖學習(增強版)的文章就介紹到這了,更多相關(guān)Java多線程 鎖內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
IDEA 集成log4j將SQL語句打印在控制臺上的實現(xiàn)操作
這篇文章主要介紹了IDEA 集成log4j將SQL語句打印在控制臺上的實現(xiàn)操作,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2021-02-02
SpringMVC Json自定義序列化和反序列化的操作方法
這篇文章主要介紹了SpringMVC Json自定義序列化和反序列化的操作方法,本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2021-01-01
關(guān)于Idea中的.properties文件顯示問題
這篇文章主要介紹了關(guān)于Idea中的.properties文件顯示問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-07-07
try catch finally的執(zhí)行順序深入分析
首先執(zhí)行try,如果有異常執(zhí)行catch,無論如何都會執(zhí)行finally,當有return以后,函數(shù)就會把這個數(shù)據(jù)存儲在某個位置,然后告訴主函數(shù),我不執(zhí)行了,接下來你執(zhí)行吧,所以函數(shù)就會推出2013-09-09
JAVA實戰(zhàn)練習之圖書管理系統(tǒng)實現(xiàn)流程
隨著網(wǎng)絡(luò)技術(shù)的高速發(fā)展,計算機應用的普及,利用計算機對圖書館的日常工作進行管理勢在必行,本篇文章手把手帶你用Java實現(xiàn)一個圖書管理系統(tǒng),大家可以在過程中查缺補漏,提升水平2021-10-10

