專欄簡介

41.redis中分布式鎖提前過期會怎么樣

在Redis中使用分布式鎖時，如果鎖提前過期，可能會引發(fā)幾個問題，主要取決于鎖的使用場景和具體的實現(xiàn)方式。分布式鎖通常用于確保在分布式系統(tǒng)中對共享資源的訪問是同步的，以避免數(shù)據(jù)不一致、數(shù)據(jù)覆蓋或其他并發(fā)問題。如果鎖提前過期，可能會有以下影響：

1. 安全性問題：如果一個進程（或線程）持有鎖進行操作，而鎖突然過期，另一個進程就可能獲得鎖并開始操作相同的資源。這可能導致數(shù)據(jù)不一致或數(shù)據(jù)損壞，因為兩個進程可能會同時修改同一資源。
2. 性能問題：鎖提前過期可能導致更多的競爭和鎖爭奪，從而增加系統(tǒng)的負載和延遲。
3. 死鎖：雖然Redis的鎖提前過期不直接導致死鎖，但如果因為鎖提前過期而引發(fā)的邏輯錯誤導致某些進程無法釋放其他資源，可能間接導致系統(tǒng)出現(xiàn)死鎖狀態(tài)。

為了減少鎖提前過期的風險和影響，可以采用以下策略：

• 合理設置鎖的過期時間：確保鎖的過期時間足夠長，以覆蓋預期內的操作時間，同時避免設置過長的過期時間，以減少資源鎖定的時間。
• 使用續(xù)租機制：對于執(zhí)行時間較長的操作，可以實現(xiàn)鎖的續(xù)租機制，即在鎖快要過期時，檢查當前進程是否仍然需要鎖，如果需要，則更新鎖的過期時間。

鎖的創(chuàng)建與過期時間設置：在Redis中，分布式鎖通常使用SET命令加上NX（只在鍵不存在時設置鍵）和PX（設置鍵的過期時間，單位為毫秒）選項來實現(xiàn)。例如，SET lock_key unique_value NX PX 30000這個命令試圖獲取一個名為lock_key的鎖，其中unique_value用于標識鎖的擁有者，確保只有鎖的持有者才能釋放該鎖。PX 30000表示這個鎖的過期時間是30000毫秒（30秒）。

鎖的續(xù)租：續(xù)租機制的實現(xiàn)需要客戶端定期更新鎖的過期時間，以防止在持有鎖的操作未完成時鎖過期。這可以通過重新設置過期時間來完成，比如使用PEXPIRE命令：PEXPIRE lock_key 30000，將lock_key的過期時間再次設置為30000毫秒。續(xù)租操作需要在一個獨立的線程或者定時任務中執(zhí)行，頻率應該小于鎖的過期時間，以確保鎖不會因為超時而被誤解。PEXPIRE 在英文中可以讀作 "P-expire"

安全的續(xù)租實現(xiàn)：為了確保續(xù)租操作的安全性，即只有鎖的持有者才能續(xù)租該鎖，可以使用Lua腳本來原子性地檢查unique_value并更新過期時間。這樣做可以避免在檢查和設置過期時間之間的時間差導致的安全問題。

 if redis.call("get", KEYS[1]) == ARGV[1] then
     return redis.call("pexpire", KEYS[1], ARGV[2])
 else
     return 0
 end

上述Lua腳本首先檢查lock_key對應的值是否為unique_value，即確認當前客戶端是否為鎖的持有者，如果是，則更新鎖的過期時間；如果不是，則不做任何操作。

鎖的釋放：鎖的持有者在操作完成后應該立即釋放鎖，這同樣可以通過一個Lua腳本安全地完成，確保只有鎖的持有者才能釋放鎖。

if redis.call("get", KEYS[1]) == ARGV[1] then
     return redis.call("del", KEYS[1])
 else
     return 0
 end

通過以上步驟，可以實現(xiàn)一個較為安全且具有續(xù)租機制的Redis分布式鎖，有效防止因操作延時導致的鎖自動釋放問題，增強了分布式環(huán)境下資源訪問的控制效率和安全性。然而，需要注意的是，Redis的鎖機制并不是完全可靠的，它依賴于網絡環(huán)境和Redis服務器的狀態(tài)。在高要求的生產環(huán)境中，可能需要結合其他工具和策略來確保分布式鎖的可靠性。

同時，一些開源的Redis客戶端或框架也提供了現(xiàn)成的分布式鎖實現(xiàn)，如Redisson，可以直接使用。 為了確保只有鎖的持有者才能續(xù)租該鎖，我們可以在獲取鎖時為鎖關聯(lián)一個唯一標識符（如UUID），然后在續(xù)租時驗證續(xù)租請求是否攜帶了與鎖關聯(lián)的標識符。這樣可以防止其他客戶端惡意續(xù)租鎖。

以下是實現(xiàn)步驟：

1. 獲取鎖時，生成一個唯一標識符（如UUID），將其與鎖的鍵一起存儲到Redis中。
2. 在續(xù)租鎖時，客戶端需要攜帶這個唯一標識符。
3. Redis使用Lua腳本來驗證續(xù)租請求的標識符與鎖關聯(lián)的標識符是否一致，只有一致時才允許續(xù)租。

• 鎖釋放的冪等性：確保鎖的釋放操作是冪等的，即多次釋放操作和一次釋放操作的效果相同，這樣即使在鎖提前過期的情況下也能安全地釋放鎖。
• 檢查鎖的擁有權：在執(zhí)行操作之前和之后，檢查當前進程是否真正擁有鎖。這可以通過在Redis中存儲一個唯一的鎖標識符來實現(xiàn)，只有當進程知道正確的標識符時才能獲得或釋放鎖。

通過上述措施，可以減輕Redis分布式鎖提前過期帶來的風險和影響，保障分布式系統(tǒng)的穩(wěn)定性和一致性。

42.jvm內存模型 堆空間的結構？分配策略有哪些？

JVM的內存模型主要分為以下幾個區(qū)域：

1. 方法區(qū)：這個區(qū)域用于存儲已被加載的類信息，常量，靜態(tài)變量，編譯器編譯后的代碼等數(shù)據(jù)。
2. 堆區(qū)：這是Java中最大的一塊存儲區(qū)域，幾乎所有的對象都是在這里分配內存的。堆是被所有線程共享的一塊區(qū)域，可被分為新生代和老年代。新創(chuàng)建的對象首先分配在新生代，經過一次 Minor GC 后，如果有存活的對象，會被移到老年代。
3. 棧區(qū)：每個線程創(chuàng)建時都會創(chuàng)建一個虛擬機棧，每個方法被執(zhí)行的時候都會動態(tài)創(chuàng)建一塊棧幀用于存儲局部變量表，操作數(shù)棧，方法出口等信息。每一個方法被調用直至執(zhí)行完成的過程，就對應著一個棧幀在虛擬機棧中入棧到出棧的過程。
4. 程序計數(shù)器（PC寄存器）：這是最小的存儲區(qū)域，其容量只有幾個字寬?？梢钥醋魇钱斍熬€程所執(zhí)行的字節(jié)碼的行號指示器。改變計數(shù)器的值來選取下一條需要執(zhí)行的字節(jié)碼指令。
5. 本地方法棧：和虛擬機棧功能類似，他們之間的區(qū)別不過是虛擬機棧為虛擬機執(zhí)行Java方法 （也就是字節(jié)碼）服務，本地方法棧則為虛擬機使用到的Native方法服務。

在Java中，堆空間（Heap Space）是由JVM在啟動時創(chuàng)建的內存區(qū)域，它用于存儲運行時數(shù)據(jù)，主要用于存放對象實例和數(shù)組。了解Java堆空間的結構對于優(yōu)化應用程序和垃圾收集（Garbage Collection, GC）有很大幫助。

堆空間的結構

Java堆空間的結構從JDK 7和JDK 8開始有所變化，這里主要介紹JDK 8及以后版本的結構：

年輕代 (Young Generation):

• Eden空間: 大多數(shù)情況下，新創(chuàng)建的對象首先被分配到Eden區(qū)。
• 幸存者區(qū) (Survivor Spaces): 包括兩個部分，Survivor from/to 1 (S1) 和 Survivor 2 (S2)。它們用來存放從Eden區(qū)經過第一次垃圾收集仍然存活的對象。

老年代 (Old Generation):

• 存放長時間存活的對象。當對象在年輕代經過一定次數(shù)的垃圾收集后仍然存活，就會被移動到老年代。

永久代/元空間 (PermGen/Metaspace，取決于JDK版本):

• JDK 7之前: 永久代（PermGen）用于存放Java類和方法信息。
• JDK 8之后: 元空間（Metaspace）替代了永久代。Metaspace并不在虛擬機的堆內存中，而是使用本地內存。這一變化是為了避免永久代內存溢出（OutOfMemoryError）的問題。

分配策略

堆空間的分配策略指的是JVM如何在堆空間中分配內存給新創(chuàng)建的對象和數(shù)組。一些常見的分配策略包括：

1. 對象優(yōu)先在Eden分配: 新建對象通常會在Eden區(qū)分配。當Eden區(qū)填滿時，會觸發(fā)一次Minor GC。
2. 大對象直接進入老年代: JVM有一個閾值來定義大對象。如果對象超過了這個大小，會直接被分配到老年代，以避免在Eden區(qū)和兩個Survivor區(qū)之間復制產生的開銷。
3. 長期存活的對象將進入老年代: 每個對象都有一個年齡計數(shù)器，當對象在年輕代中存活足夠的垃圾收集周期，并且超過了某個年齡閾值后，會被移動到老年代。
4. 動態(tài)對象年齡判定: 如果Survivor空間中相同年齡所有對象大小的總和超過Survivor空間的一半，年齡大于或等于該年齡的對象就可以直接進入老年代，無需等到閾值年齡。 至于為什么這個規(guī)則不適用于Eden空間，原因是Eden空間和Survivor空間的使用目標不同。Eden空間主要用于存放新創(chuàng)建的對象，而Survivor空間則用于存放已經存活的對象，因此，對于長時間存活的對象，我們希望它們能夠盡快被移到老年區(qū)，以保持Survivor空間的流動性。
5. 空間分配擔保: 在發(fā)生Minor GC之前，虛擬機會檢查老年代最大可用的連續(xù)空間是否大于年輕代所有對象的總空間，如果不足，則進行Full GC來清理老年代的空間。

43.linux文件有哪些類型？各自的作用是什么？

在Linux操作系統(tǒng)中，文件是存儲數(shù)據(jù)的基本單位。Linux中的文件類型多樣，每種類型的文件都有其特定的作用和用途。以下是Linux中常見的幾種文件類型及其作用：

1. 普通文件（Regular Files）：這是最常見的文件類型，用于存儲數(shù)據(jù)，比如文本文件、程序腳本或二進制程序等。普通文件可以包含文本、源代碼或程序數(shù)據(jù)。
2. 目錄（Directories）：目錄是一種特殊類型的文件，用于組織文件系統(tǒng)中的文件和其他目錄。目錄文件包含了它所包含的文件和目錄的列表及其相關信息。
3. 字符設備文件（Character Device Files）：這種文件類型代表一種設備，比如鍵盤、鼠標或其他輸入/輸出設備，它們是以字符流的形式進行數(shù)據(jù)傳輸?shù)摹?/li>
4. 塊設備文件（Block Device Files）：塊設備文件也代表設備，但與字符設備不同，它們以數(shù)據(jù)塊的形式存儲數(shù)據(jù)，通常用于磁盤驅動器或其他存儲設備。
5. 鏈接（Links）：鏈接是指向另一個文件的引用。有兩種類型的鏈接：硬鏈接（hard link）和符號鏈接（symbolic link，又稱軟鏈接）。硬鏈接是對文件的另一個引用，它與原文件共享相同的數(shù)據(jù)。符號鏈接則是一個特殊的文件，包含了另一個文件的路徑。
6. 管道（Pipes）：管道是一種特殊類型的文件，主要用于進程間通信。它允許一個進程和另一個進程之間的數(shù)據(jù)流動。
7. 套接字（Sockets）：套接字也是一種特殊類型的文件，用于在網絡中的不同主機間或同一主機上的不同進程間進行通信。
8. 設備文件（Device Files）：設備文件是系統(tǒng)用來訪問硬件設備的接口文件，包括字符設備文件和塊設備文件。

每種文件類型在Linux系統(tǒng)中扮演著不同的角色，它們共同協(xié)作，使得Linux系統(tǒng)能夠高效地管理數(shù)據(jù)和資源。

44.inode的作用？inode包含哪些內容？給出一個文件名，Linux是如何根據(jù)該文件名打開文件的？（文件名->inode->block）文件的訪問時間是如何記錄的？

在Linux文件系統(tǒng)中，inode（索引節(jié)點）是一個非常核心的概念，它用于存儲文件的元數(shù)據(jù)（不包括文件名和文件實際內容）。每個文件或目錄都有一個與之對應的inode，其中包含了該文件的幾乎所有信息。

inode的作用

• 存儲文件元數(shù)據(jù)：inode存儲了關于文件的所有基本信息，除了文件名和實際數(shù)據(jù)內容。
• 文件系統(tǒng)操作：在執(zhí)行文件系統(tǒng)操作如打開、讀取、寫入文件時，系統(tǒng)會使用inode中的信息來進行這些操作。

inode包含的內容

inode包含的信息大致可以分為以下幾類：

• 文件類型：文件是普通文件、目錄還是鏈接文件等。
• 權限和所有權：文件的訪問權限（讀、寫、執(zhí)行）以及文件的所有者和所屬組。
• 時間戳：文件的創(chuàng)建時間、最后訪問時間、最后修改時間等。
• 文件大小：文件內容的大?。ㄗ止?jié)為單位）。
• 指向文件數(shù)據(jù)塊的指針：這些指針實際上指向存儲文件數(shù)據(jù)的磁盤塊。

從文件名到打開文件的過程

當給出一個文件名時，Linux系統(tǒng)如何根據(jù)該文件名打開文件的過程通常遵循以下步驟：

1. 查找目錄項：系統(tǒng)首先在當前目錄下查找文件名對應的目錄項。目錄本身也是一種文件，其內容是一系列的目錄項，每個目錄項將一個文件名映射到一個inode號。
2. 獲取inode：一旦找到文件名對應的目錄項，系統(tǒng)就會讀取該目錄項中的inode號，并通過這個inode號在文件系統(tǒng)的inode表中找到對應的inode。
3. 讀取文件數(shù)據(jù)：系統(tǒng)根據(jù)inode中存儲的文件數(shù)據(jù)塊位置信息，找到文件數(shù)據(jù)存儲在磁盤上的位置，進而可以讀取、寫入或修改文件數(shù)據(jù)。

45.零拷貝是什么？用來解決什么問題？有哪些應用場景？實現(xiàn)方式有哪些？

實現(xiàn)方式

零拷貝可以通過多種方式實現(xiàn)，常見的實現(xiàn)方式包括：

1. 利用內存映射（mmap）：通過內存映射，應用程序可以直接訪問磁盤上的文件，而無需將文件內容讀入到用戶空間的緩沖區(qū)中，減少了一次數(shù)據(jù)復制。
2. 直接I/O：直接I/O繞過了操作系統(tǒng)的緩存，允許磁盤I/O操作直接在用戶空間緩沖區(qū)和磁盤之間傳輸數(shù)據(jù)，避免了數(shù)據(jù)在用戶空間和內核空間之間的多次復制。
3. sendfile系統(tǒng)調用：sendfile是Linux提供的一種高效的數(shù)據(jù)傳輸方式，它可以直接在文件描述符之間傳輸數(shù)據(jù)，繞過用戶空間，減少數(shù)據(jù)復制。
4. Linux的splice和tee系統(tǒng)調用：splice可以將數(shù)據(jù)從一個文件描述符移動到另一個文件描述符中，而不需要將數(shù)據(jù)復制到用戶空間。tee用于在兩個文件描述符之間復制數(shù)據(jù)，同時避免了數(shù)據(jù)復制到用戶空間。

46.TCP 和 UDP 可以使用同一個端口嗎？

TCP和UDP可以使用同一個端口號，因為它們是兩種不同的協(xié)議，操作在不同的網絡層。在網絡中，一個端口號的唯一性是由IP地址、端口號以及協(xié)議三者共同決定的。這意味著TCP和UDP各自可以綁定相同的端口號，而不會產生沖突，因為協(xié)議類型（TCP或UDP）作為區(qū)分。這種機制允許應用程序同時或分別監(jiān)聽相同的端口號上的TCP和UDP流量。

舉例來說，DNS服務就是一個典型的例子，它通常同時在UDP和TCP的53端口上監(jiān)聽。對于大多數(shù)查詢，DNS使用UDP協(xié)議，因為它更快，且DNS請求和響應通常都很小，適合UDP。然而，當DNS響應數(shù)據(jù)較大時，超過了UDP的限制，就會改用TCP協(xié)議，以確保數(shù)據(jù)的完整性和可靠性。

因此，在設計和部署網絡應用程序時，可以根據(jù)需要，為同一端口號配置TCP和UDP協(xié)議，這不會引起端口沖突，只要保證同一協(xié)議類型下，端口號的唯一性即可。

47.MySQL 存儲引擎特性對比及 InnoDB 的主導地位分析

MySQL 提供了多種存儲引擎，用于滿足不同的數(shù)據(jù)存儲、性能和功能需求。選擇合適的存儲引擎對于數(shù)據(jù)庫的效率和穩(wěn)定性至關重要。其中，InnoDB 和 MyISAM 是最廣為人知的兩種引擎，但 MySQL 還提供了其他各具特色的引擎。

InnoDB 是 MySQL 的默認存儲引擎（自 5.5.5 版本起），其核心優(yōu)勢在于全面支持 ACID 事務，包括提交、回滾和崩潰恢復機制，極大地保障了數(shù)據(jù)的完整性和一致性。它支持行級鎖定，在高并發(fā)場景下能提供更好的性能表現(xiàn)，并支持外鍵約束來維護數(shù)據(jù)間的引用完整性。這些特性使得 InnoDB 非常適用于需要高可靠性、事務支持和并發(fā)處理的在線事務處理（OLTP）系統(tǒng)。

MyISAM 曾是 MySQL 的默認引擎，它不支持事務和外鍵，采用表級鎖定，這在高并發(fā)寫入場景下可能導致性能瓶頸。然而，MyISAM 在讀取密集型操作、數(shù)據(jù)檢索以及全文搜索方面表現(xiàn)出色，因此常被用于只讀或讀遠多于寫的應用，如數(shù)據(jù)倉庫或某些 Web 應用場景。

除了 InnoDB 和 MyISAM，MySQL 還提供其他專用引擎： MEMORY 引擎將數(shù)據(jù)存儲在內存中，提供極快的訪問速度，適用于緩存或臨時數(shù)據(jù)存儲，但數(shù)據(jù)會在服務重啟后丟失； Archive 引擎專為存儲大量歸檔數(shù)據(jù)（如日志）設計，具有高壓縮比，但僅支持插入和查詢操作； CSV 引擎以逗號分隔的文本文件形式存儲數(shù)據(jù)，便于數(shù)據(jù)的導入導出； Federated 引擎允許用戶訪問遠程 MySQL 服務器上的表； BLACKHOLE 引擎則是一個“黑洞”，它接受寫入但不存儲數(shù)據(jù)，常用于數(shù)據(jù)復制中繼或性能測試場景。

InnoDB 之所以成為最廣泛使用的存儲引擎，主要是因為它提供了一套關鍵的企業(yè)級特性。對事務（ACID）的完整支持確保了數(shù)據(jù)操作的原子性、一致性、隔離性和持久性，這對于金融、電商等關鍵業(yè)務系統(tǒng)至關重要。其強大的崩潰恢復能力和通過行級鎖定實現(xiàn)的高并發(fā)性能，進一步提升了數(shù)據(jù)庫的穩(wěn)定性和響應速度。同時，外鍵約束有助于在數(shù)據(jù)庫層面強制實施數(shù)據(jù)間的關聯(lián)關系，保證了數(shù)據(jù)的引用完整性。綜合這些優(yōu)點，InnoDB 成為了大多數(shù)現(xiàn)代應用開發(fā)的首選。

48.spring配置加載順序

Spring Framework 在啟動時加載配置文件的順序遵循一定的規(guī)則，以確保配置的靈活性和可覆蓋性。Spring Boot 進一步增強了這一機制，提供了一個多層次、有序的配置加載方式，允許從不同的來源讀取配置，包括屬性文件、YAML文件、環(huán)境變量和命令行參數(shù)等。以下是Spring Boot中配置加載的一般順序，從高優(yōu)先級到低優(yōu)先級：

1. 命令行參數(shù)：任何直接在命令行上傳遞的參數(shù)（例如，使用--name=value的形式）。
2. 來自Java系統(tǒng)屬性（System Properties）的配置：通過System.getProperties()設置的屬性。
3. 操作系統(tǒng)環(huán)境變量：系統(tǒng)級別的環(huán)境變量。
4. JNDI屬性：在Java命名和目錄接口（JNDI）下的java:comp/env中查找的屬性。
5. Java配置類：通過@Configuration注解標注的類，內部使用@Bean定義的配置信息。
6. Spring Boot應用程序屬性位于application.properties或application.yml文件中的配置，這些文件可以位于多個位置，優(yōu)先級按照以下順序：
7. file:./config/
8. file:./
9. classpath:/config/
10. classpath:/ 對于上述位置，優(yōu)先加載位于./config/下的配置文件，其次是位于當前目錄下的，然后是類路徑/config/下的，最后是類路徑根下的。
11. 在配置服務器上的配置（如果使用Spring Cloud Config Server）。
12. 打包在應用程序內的配置：應用內部的application.properties或application.yml文件。
13. 通過@PropertySource注解指定的屬性文件：在配置類中，可以使用@PropertySource注解指定要加載的屬性文件。
14. 默認屬性：通過SpringApplication.setDefaultProperties指定的默認屬性。

49.spring源碼的設計模式有啥在哪用到了

Spring Framework 的設計和架構中廣泛使用了設計模式，以提供靈活、高效和可擴展的開發(fā)框架。以下是一些在Spring源碼中常見的設計模式及其應用示例：

單例模式（Singleton Pattern）：

• 用于Sprin