欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

面試總結(jié):秒殺設(shè)計、AQS 、synchronized相關(guān)問題

 更新時間:2021年06月28日 16:00:14   作者:興趣使然的草帽路飛  
Java語言的關(guān)鍵字,當(dāng)它用來修飾一個方法或者一個代碼塊的時候,能夠保證在同一時刻最多只有一個線程執(zhí)行該段代碼。本文給大家介紹java中 synchronized的用法,對本文感興趣的朋友一起看看吧

1、面試官:如何設(shè)計一個秒殺系統(tǒng)?請你闡述流程?

這是一篇參考的文章:如何設(shè)計一個秒殺系統(tǒng)

秒殺系統(tǒng)要解決的幾個問題?

① 高并發(fā)

秒殺的特點是時間極短、 瞬間用戶量大。在秒殺活動持續(xù)時間內(nèi),Redis 服務(wù)器需要承受大量的用戶請求,在大量請求條件下,緩存雪崩,緩存擊穿,緩存穿透這些問題都是有可能發(fā)生的。

一旦緩存失效,或者緩存無效,每秒上萬甚至十幾萬的QPS(每秒請求數(shù))直接打到數(shù)據(jù)庫,基本上都要把庫打掛掉,而且你的服務(wù)不單單是做秒殺的還涉及其他的業(yè)務(wù),你沒做降級、限流、熔斷啥的,別的一起掛,小公司的話可能全站崩潰404。

為此,在設(shè)計秒殺系統(tǒng)時,首先要考慮并發(fā)安全和用戶訪問效率,二者缺一不可!

② 超賣

但凡設(shè)計到商品購買,秒殺購物問題,最需要注意的就是超賣問題,因為一旦由于程序不安全,導(dǎo)致超賣問題產(chǎn)生,不光需要賠付商家損失,還需要追究秒殺系統(tǒng)的開發(fā)者的責(zé)任!

③ 惡意請求

在秒殺購物時,商品價格比較低,價值較高的商品可能會被一些惡意的第三方,開多臺機(jī)器執(zhí)行搶購腳本,機(jī)器搶購肯定要比我們?nèi)耸謩狱c擊要快,所以,在設(shè)計秒殺系統(tǒng)時,要防止 不良程序員 的惡意搶購。

④ 鏈接暴露

假如設(shè)置定時秒殺開啟,在未到秒殺開啟時間之前,下單購買按鈕應(yīng)該是禁用的(不可點擊),但是,如果我們請求下單的鏈接沒有經(jīng)過網(wǎng)關(guān)加密封裝,而是直接以原鏈接的方式依附于下單購買按鈕,那么 F12 時,就可以獲取下單購買鏈接 URL,然后直接去請求下單鏈接,跳過點擊方式直接購買商品!

如何解決上面遇到的幾個問題?

① 秒殺模塊微服務(wù)化

對于秒殺搶購系統(tǒng),將其設(shè)計成單獨一個模塊,單獨部署一臺或者多太服務(wù)器,這樣可以避免服務(wù)崩潰時,公司其他項目可以正常運(yùn)行不受影響。

與此同時,要單獨給秒殺系統(tǒng)建立一個數(shù)據(jù)庫,現(xiàn)在的互聯(lián)網(wǎng)架構(gòu)部署都是分庫的,一樣的就是訂單服務(wù)對應(yīng)訂單庫,秒殺我們也給他建立自己的秒殺數(shù)據(jù)庫,防止服務(wù)崩潰對其他數(shù)據(jù)庫造成影響。

② 秒殺鏈接加鹽

URL動態(tài)化,通過 MD5 之類的加密算法加密隨機(jī)的字符串去做 URL,然后通過前端代碼獲取 URL 后臺校驗后才能通過。

③ Redis集群

如果在大請求量下,單機(jī)的Redis頂不住,那就多找?guī)讉€兄弟,秒殺本來就是讀多寫少,通過 Redis 集群,主從同步、讀寫分離,再加上 哨兵、開啟 持久化,來保證 Redis 服務(wù)高可用!

④ 通過 Nginx 做負(fù)載均衡

Nginx高性能的web服務(wù)器,并發(fā)隨便頂幾萬不是夢,但是我們的 Tomcat 只能頂幾百的并發(fā),我們可以通過Nginx 負(fù)載均衡,平分大并發(fā)量的請求給多臺服務(wù)器的 Tomcat,在秒殺開啟的時候可以多租點流量機(jī)

⑤ 秒殺頁面資源靜態(tài)化

秒殺一般都是特定的商品還有頁面模板,現(xiàn)在一般都是前后端分離的,所以頁面一般都是不會經(jīng)過后端的,但是前端也要自己的服務(wù)器啊,那就把能提前放入**cdn服務(wù)器 **的東西都放進(jìn)去,反正把所有能提升效率的步驟都做一下,減少真正秒殺時候服務(wù)器的壓力。

⑥ 下單按鈕控制

在沒到秒殺開始時間之前,一般下單按鈕都是置灰的,只有時間到了,才能點擊。這是因為怕大家在時間快到的最后幾秒秒瘋狂請求服務(wù)器,然后還沒到秒殺的時候基本上服務(wù)器就掛了。

這個時候就需要前端的配合,定時去請求你的后端服務(wù)器,獲取最新的北京時間,到時間點再給按鈕可用狀態(tài)。按鈕可以點擊之后也得給他置灰?guī)酌耄蝗凰粯釉陂_始之后一直點的。

⑦ 前后端限流

限流可以分為 前端限流后端限流。

前端限流:這個很簡單,一般秒殺搶購,下單按鈕不會讓你一直點的,一般都是點擊一下或者兩下然后幾秒之后才可以繼續(xù)點擊,這也是保護(hù)服務(wù)器的一種手段。

后端限流:秒殺的時候肯定是涉及到后續(xù)的訂單生成和支付等操作,但是都只是成功的幸運(yùn)兒才會走到那一步,那一旦 100 個產(chǎn)品賣光了,return 了一個 false,前端直接秒殺結(jié)束,然后你后端也關(guān)閉后續(xù)無效請求的介入了。

⑧ 庫存預(yù)熱

秒殺的本質(zhì),就是對庫存的搶奪。如果每個秒殺下單的用戶請求過來,都去數(shù)據(jù)庫查詢庫存校驗庫存,然后扣減庫存,這樣不光效率低下,而且數(shù)據(jù)庫壓力也是巨大的!

既然數(shù)據(jù)庫頂不住,但是他的兄弟非關(guān)系型的數(shù)據(jù)庫 Redis 能頂啊!

超賣問題:

我們要在開始秒殺之前,通過定時任務(wù)提前把商品的庫存加載到 Redis 中去,讓整個庫存校驗流程都在 Redis 里面去做,然后等到秒殺活動結(jié)束了,再異步的去修改數(shù)據(jù)庫中庫存就好了。

但是用了 Redis 就有一個問題了,我們上面說了我們采用 主從 Redis,就是我們會先去讀取庫存,再判斷庫存,當(dāng)有庫存時才會去減庫存,正常情況沒問題,但是高并發(fā)的情況問題就很大了。

就比如現(xiàn)在庫存只剩下 1 個了,我們高并發(fā)嘛,4 個服務(wù)器一起查詢了發(fā)現(xiàn)都是還有 1 個,那大家都覺得是自己搶到了,就都去扣庫存,那結(jié)果就變成了 -3,這種情況下,只有一個請求是真的搶到商品了,其他 3 個都是超賣的。

如何解決?

可以通過使用 Lua 腳本來解決超賣問題。

**Lua 腳本是類似Redis事務(wù),有一定的原子性,不會被其他命令插隊,可以完成一些 Redis 事務(wù)性的操作。**這點是關(guān)鍵!

把判斷庫存、扣減庫存的操作都寫在一個 Lua 腳本中,并將該腳本交給 Redis 去執(zhí)行,當(dāng) Redis 中庫存數(shù)量減到 0 之后,后面扣庫存的請求都直接 return false。

⑨ 限流&降級&熔斷&隔離

不怕一萬就怕萬一,萬一秒殺系統(tǒng)真的頂不住了,限流,頂不住就擋一部分出去。但是不能說不行,降級,降級了還是被打掛了,熔斷,至少不要影響別的系統(tǒng),隔離,你本身就獨立的,但是你會調(diào)用其他的系統(tǒng)嘛,你快不行了你別拖累兄弟們啊。

2、面試官:AQS源碼有了解過嗎?請你說一下加鎖和釋放鎖的流程

這一面試題答案參考自三太子敖丙的文章:深入淺出學(xué)習(xí)AQS組件

① AQS紹

AQS中 維護(hù) 基本介了一個volatile int state(代表共享資源)和一個 FIFO 線程等待隊列(多線程爭用資源被阻塞時會進(jìn)入此隊列)。

這里volatile能夠保證多線程下的可見性,當(dāng)state = 1則代表當(dāng)前對象鎖已經(jīng)被占有,其他線程來加鎖時則會失敗,加鎖失敗的線程會被放入一個 FIFO的等待隊列中,并會被 UNSAFE.park() 操作掛起,等待其他獲取鎖的線程釋放鎖才能夠被喚醒。

另外state的操作都是通過CAS來保證其并發(fā)修改的安全性。

如圖所示:

AQS 中提供了很多關(guān)于鎖的實現(xiàn)方法:

getState():獲取鎖的標(biāo)志 state 值。

setState():設(shè)置鎖的標(biāo)志 state 值。

tryAcquire(int):獨占方式獲取鎖。嘗試獲取資源,成功則返回 true,失敗則返回 false。

tryRelease(int):獨占方式釋放鎖。嘗試釋放資源,成功則返回 true,失敗則返回 false。

② 加鎖與競爭鎖使用場景分析

如果同時有三個線程并發(fā)搶占鎖,此時線程一搶占鎖成功,線程二和線程三搶占鎖失敗,具體執(zhí)行流程如下:

此時AQS內(nèi)部數(shù)據(jù)為:

具體看下?lián)屨兼i代碼實現(xiàn):java.util.concurrent.locks.ReentrantLock .NonfairSync

static final class NonfairSync extends Sync {
    // 加鎖
    final void lock() {
        // CAS 修改 state 的值為 1
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);
    }
    // 嘗試競爭資源
    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);
    }
}

這里使用的 ReentrantLock 非公平鎖,線程進(jìn)來直接利用CAS嘗試搶占鎖,如果搶占成功state值回被改為 1,且設(shè)置獨占鎖線程對象為當(dāng)前線程。

// CAS 嘗試搶占鎖
protected final boolean compareAndSetState(int expect, int update) {
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
// 設(shè)置獨占鎖線程對象為當(dāng)前線程
protected final void setExclusiveOwnerThread(Thread thread) {
    exclusiveOwnerThread = thread;
}

線程一搶占鎖成功后,state變?yōu)?1,線程二通過CAS修改state變量必然會失敗。此時AQSFIFO(First In First Out 先進(jìn)先出)隊列中。

public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

tryAcquire() 方法的具體實現(xiàn)是通過內(nèi)部調(diào)用nonfairTryAcquire()方法,這個方法執(zhí)行的邏輯如下:

首先會獲取state的值,如果不為0則說明當(dāng)前對象的鎖已經(jīng)被其他線程所占有。

接著判斷占有鎖的線程是否為當(dāng)前線程,如果是則累加state值,這就是可重入鎖的具體實現(xiàn),累加state值,釋放鎖的時候也要依次遞減state值。

如果state為 0,則執(zhí)行CAS操作,嘗試更新state值為 1,如果更新成功則代表當(dāng)前線程加鎖成功。

③ 釋放鎖使用場景分析

釋放鎖的過程,首先是線程一釋放鎖,釋放鎖后會喚醒head節(jié)點的后置節(jié)點,也就是我們現(xiàn)在的線程二,具體操作流程如下:

執(zhí)行完后等待隊列數(shù)據(jù)如下:

此時線程二已經(jīng)被喚醒,繼續(xù)嘗試獲取鎖,如果獲取鎖失敗,則會繼續(xù)被掛起。

線程釋放鎖的代碼:

java.util.concurrent.locks.AbstractQueuedSynchronizer.release():

public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}

這里首先會執(zhí)行tryRelease()方法,這個方法具體實現(xiàn)在ReentrantLock中,如果tryRelease()執(zhí)行成功,則繼續(xù)判斷 head 節(jié)點的 waitStatus 是否為 0,前面我們已經(jīng)看到過,headwaitStatue為SIGNAL(-1),這里就會執(zhí)行 unparkSuccessor() 方法來喚醒 head 的后置節(jié)點,也就是上面圖中線程二對應(yīng)的Node節(jié)點。

ReentrantLock.tryRelease():

protected final boolean tryRelease(int releases) {
    int c = getState() - releases;
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    setState(c);
    return free;
}

執(zhí)行完ReentrantLock.tryRelease()后,state被設(shè)置成 0,Lock 對象的獨占鎖被設(shè)置為 null。

接著執(zhí)行java.util.concurrent.locks.AbstractQueuedSynchronizer.unparkSuccessor()方法,喚醒head的后置節(jié)點:

private void unparkSuccessor(Node node) {
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);
    Node s = node.next;
    if (s == null || s.waitStatus > 0) {
        s = null;
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)
                s = t;
    }
    if (s != null)
        LockSupport.unpark(s.thread);
}

這里主要是將head節(jié)點的waitStatus設(shè)置為 0,然后解除head節(jié)點next的指向,使head節(jié)點空置,等待著被垃圾回收。

此時重新將head指針指向線程二對應(yīng)的Node節(jié)點,且使用LockSupport.unpark方法來喚醒線程二。

被喚醒的線程二會接著嘗試獲取鎖,用CAS指令修改state數(shù)據(jù)。

3、面試官:請你談一談synchronized的實現(xiàn)原理

這一面試題答案參考文章:死磕 java同步系列之synchronized解析

synchronized 加鎖解鎖原理分析

sychronized 鎖,在Java內(nèi)存模型層面,涉及到 2 個指令(JMM 定義了8 個操作來完成主內(nèi)存工作內(nèi)存的交互操作,參考文章:搜集了這么多資料,不信你還理解不了 JMM 內(nèi)存模型、volatile 關(guān)鍵字保證有序性和可見性實現(xiàn)原理?。?,lockunlock

  • lock,鎖定,作用于主內(nèi)存的變量,它把主內(nèi)存中的變量標(biāo)識為線程獨占狀態(tài)。
  • unlock,解鎖,作用于主內(nèi)存的變量,它把鎖定的變量釋放出來,釋放出來的變量才可以被其它線程鎖定。

這兩個指令并沒有直接提供給用戶使用,而是提供了兩個更高層次的指令 monitorenter monitorexit 來隱式地使用 lock unlock 指令。而 synchronized 就是使用 monitorenter monitorexit 這兩個指令來實現(xiàn)的。

根據(jù)JVM規(guī)范的要求,在執(zhí)行 monitorenter 指令的時候,首先要去嘗試獲取對象的鎖,如果這個對象沒有被鎖定,或者當(dāng)前線程已經(jīng)擁有了這個對象的鎖,就把鎖的計數(shù)器加1,相應(yīng)地,在執(zhí)行 monitorexit 的時候會把計數(shù)器減 1,當(dāng)計數(shù)器減小為 0 時,鎖就釋放了。

sychronized 鎖是如何保證,原子性、可見性、和一致性呢?

還是回到Java內(nèi)存模型上來,synchronized關(guān)鍵字底層是通過 monitorenter monitorexit 實現(xiàn)的,而這兩個指令又是通過 lockunlock 來實現(xiàn)的。

lock unlock 在Java內(nèi)存模型中是必須滿足下面四條規(guī)則的:

  • ① 一個變量同一時刻只允許一條線程對其進(jìn)行 lock 操作,但 lock 操作可以被同一個線程執(zhí)行多次,多次執(zhí)行 lock 后,只有執(zhí)行相同次數(shù)的 unlock 操作,變量才能被解鎖。
  • ② 如果對一個變量執(zhí)行 lock 操作,將會清空工作內(nèi)存中此變量的值,在執(zhí)行引擎使用這個變量前,需要重新執(zhí)行 load assign 操作初始化變量的值;
  • ③ 如果一個變量沒有被 lock 操作鎖定,則不允許對其執(zhí)行 unlock 操作,也不允許 unlock 一個其它線程鎖定的變量;
  • ④ 對一個變量執(zhí)行 unlock 操作之前,必須先把此變量同步回主內(nèi)存中,即執(zhí)行 storewrite 操作;

通過規(guī)則 ①,我們知道對于 lock unlock 之間的代碼,同一時刻只允許一個線程訪問,所以,synchronized 是具有原子性的。

通過規(guī)則 ① ② 和 ④,我們知道每次 lockunlock 時都會從主內(nèi)存加載變量或把變量刷新回主內(nèi)存,而 lock 和 unlock 之間的變量(這里是指鎖定的變量)是不會被其它線程修改的,所以,synchronized 是具有可見性的。

通過規(guī)則 ① 和 ③ ,我們知道所有對變量的加鎖都要排隊進(jìn)行,且其它線程不允許解鎖當(dāng)前線程鎖定的對象,所以,synchronized 是具有有序性的。

綜上所述,synchronized 是可以保證原子性、可見性和有序性的。

synchronized 鎖優(yōu)化

Java在不斷進(jìn)化,同樣地,Java 中像 synchronized 這種關(guān)鍵字也在不斷優(yōu)化,synchronized 有如下三種狀態(tài):

  • 偏向鎖,是指一段同步代碼一直被一個線程訪問,那么這個線程會自動獲取鎖,降低獲取鎖的代價。
  • 輕量級鎖,是指當(dāng)鎖是偏向鎖時,被另一個線程所訪問,偏向鎖會升級為輕量級鎖,這個線程會通過自旋的方式嘗試獲取鎖,不會阻塞,提高性能。
  • 重量級鎖,是指當(dāng)鎖是輕量級鎖時,當(dāng)自旋的線程自旋了一定的次數(shù)后,還沒有獲取到鎖,就會進(jìn)入阻塞狀態(tài),該鎖升級為重量級鎖,重量級鎖會使其他線程阻塞,性能降低。

總結(jié)

(1)synchronized 在編譯時會在同步塊前后生成 monitorenter monitorexit 字節(jié)碼指令;

(2)monitorentermonitorexit 字節(jié)碼指令需要一個引用類型的參數(shù),基本類型不可以哦;

(3)monitorentermonitorexit 字節(jié)碼指令更底層是使用Java內(nèi)存模型的 lock 和 unlock 指令;

(4)synchronized 是可重入鎖;

(5)synchronized 是非公平鎖;

(6)synchronized 可以同時保證原子性、可見性、有序性;

(7)synchronized 有三種狀態(tài):偏向鎖、輕量級鎖、重量級鎖;

本篇文章就到這里了,希望能給你帶來幫助,也希望你能夠多多關(guān)注腳本之家的更多內(nèi)容!

相關(guān)文章

  • Redis Lettuce連接redis集群實現(xiàn)過程詳細(xì)講解

    Redis Lettuce連接redis集群實現(xiàn)過程詳細(xì)講解

    這篇文章主要介紹了Redis Lettuce連接redis集群實現(xiàn)過程,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)吧
    2023-01-01
  • SpringBoot?項目打成?jar后加載外部配置文件的操作方法

    SpringBoot?項目打成?jar后加載外部配置文件的操作方法

    這篇文章主要介紹了SpringBoot?項目打成?jar后加載外部配置文件的操作方法,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下
    2023-03-03
  • idea啟動springmvc項目時報找不到類的解決方法

    idea啟動springmvc項目時報找不到類的解決方法

    這篇文章主要介紹了idea啟動springmvc項目時報找不到類的解決方法,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下
    2020-09-09
  • 解決FeignClient發(fā)送post請求異常的問題

    解決FeignClient發(fā)送post請求異常的問題

    這篇文章主要介紹了FeignClient發(fā)送post請求異常的問題,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教
    2021-07-07
  • Java實現(xiàn)的AES256加密解密功能示例

    Java實現(xiàn)的AES256加密解密功能示例

    這篇文章主要介紹了Java實現(xiàn)的AES256加密解密功能,結(jié)合完整實例形式分析了Java實現(xiàn)AES256加密解密功能的步驟與相關(guān)操作技巧,需要的朋友可以參考下
    2017-02-02
  • Window搭建部署RocketMQ步驟詳解

    Window搭建部署RocketMQ步驟詳解

    這篇文章主要介紹了Window搭建部署RocketMQ步驟詳解,RocketMq是一個由阿里巴巴開源的消息中間件,脫胎去阿里每部使用的MetaQ,在設(shè)計上借鑒了Kafka。,需要的朋友可以參考下
    2019-06-06
  • IntelliJ IDEA使用git初始化倉庫的使用方法

    IntelliJ IDEA使用git初始化倉庫的使用方法

    這篇文章主要介紹了IntelliJ IDEA使用git初始化倉庫的使用方法,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下
    2021-04-04
  • 被遺忘的Java關(guān)鍵字transient的使用詳解

    被遺忘的Java關(guān)鍵字transient的使用詳解

    在 Java 中,transient 是一個關(guān)鍵字,用于指定一個類的字段(成員變量)在序列化時應(yīng)該被忽略。本文將通過示例為大家簡單講講transient的使用,需要的可以參考一下
    2023-04-04
  • 在Android系統(tǒng)中使用WebViewClient處理跳轉(zhuǎn)URL的方法

    在Android系統(tǒng)中使用WebViewClient處理跳轉(zhuǎn)URL的方法

    這篇文章主要介紹了在Android系統(tǒng)中使用WebViewClient處理跳轉(zhuǎn)URL的方法,實現(xiàn)代碼為Java語言編寫,是需要的朋友可以參考下
    2015-07-07
  • 減小Maven項目生成的JAR包體積實現(xiàn)提升運(yùn)維效率

    減小Maven項目生成的JAR包體積實現(xiàn)提升運(yùn)維效率

    在Maven構(gòu)建Java項目過程中,減小JAR包體積可通過排除不必要的依賴和使依賴jar包獨立于應(yīng)用jar包來實現(xiàn),在pom.xml文件中使用<exclusions>標(biāo)簽排除不需要的依賴,有助于顯著降低JAR包大小,此外,將依賴打包到應(yīng)用外,可減少應(yīng)用包的體積
    2024-10-10

最新評論