Java 2023年接地氣的中高級面試題一（附答案）

直入主題：

Q1：為什么要用分布式鎖？

　　在分布式系統中，多個行程或執行緒可能會同時訪問共享資源，這可能會導致資料不一致、并發性問題、性能下降等問題，為了解決這些問題，我們通常會使用分布式鎖來協調多個行程或執行緒對共享資源的訪問，

　　分布式鎖是一種協調機制，它通過在共享資源上設定鎖來防止多個行程或執行緒同時訪問它，分布式鎖的主要作用如下：

1. 保證資料的一致性：通過分布式鎖來控制對共享資源的訪問，可以避免多個行程或執行緒同時修改同一份資料而導致的資料不一致問題，

2. 提高并發性：通過使用分布式鎖，可以保證每個行程或執行緒在訪問共享資源時都是排他的，從而避免了并發訪問的問題，提高了系統的并發性，

3. 避免死鎖：分布式鎖通常會設定超時時間，當一個行程或執行緒獲取到鎖后在一定時間內未能完成操作，鎖會自動釋放，避免了死鎖的問題，

　　總之，使用分布式鎖可以幫助我們在分布式系統中實作資料的一致性、提高系統的并發性和穩定性，從而保證系統的可靠性和高可用性，

Q2：分布式鎖用的redis的哪種結構？

　　Redis提供了多種實作分布式鎖的方式，常見的有以下兩種：

1. 基于SETNX命令的實作方式：該方式利用Redis的SETNX命令實作分布式鎖，具體實作流程如下：

   • 在Redis中創建一個鍵值對，鍵為鎖的名稱，值為任意字串；
   • 當某個行程需要獲取鎖時，它通過SETNX命令嘗試在Redis中創建該鎖對應的鍵值對，如果創建成功（即回傳1），則該行程獲取到鎖，如果創建失敗（即回傳0），則該行程獲取鎖失敗；
   • 當某個行程需要釋放鎖時，它通過DEL命令洗掉該鎖對應的鍵值對，

2. 基于Redlock演算法的實作方式：該方式是一種分布式鎖的演算法，由Redis官方提出，基于多個Redis實體之間的協調實作分布式鎖，具體實作流程如下：

   • 在多個Redis實體上創建相同的鎖，即相同的鎖名稱和鎖值；
   • 當某個行程需要獲取鎖時，它依次在多個Redis實體上獲取鎖，每個Redis實體的獲取鎖程序與上述基于SETNX命令的方式類似；
   • 當某個行程需要釋放鎖時，它依次在多個Redis實體上釋放鎖，每個Redis實體的釋放鎖程序與上述基于SETNX命令的方式類似；
   • Redlock演算法規定，只有當大多數（超過半數）的Redis實體上的鎖都被某個行程獲取時，該行程才算獲取到了鎖，

　　以上兩種方式都是基于Redis的資料結構實作的分布式鎖，具體實作方式有所不同，但都可以有效地解決分布式系統中的并發問題，

Q3：為什么字串結構不能用來做分布式？

　　Redis中的字串結構可以用來存盤資料，但不能用來實作分布式鎖，這是因為，在分布式系統中，多個行程或執行緒可能同時訪問共享資源，為了保證資料的一致性和正確性，需要實作對共享資源的互斥訪問，而字串結構并不支持互斥訪問，也就無法保證共享資源的正確性和一致性，

　　另外，即使是對于單機環境，使用字串結構來實作鎖也是不可行的，因為在Redis中，字串是原子操作的，即每次操作都是原子性的，但在分布式系統中，多個行程或執行緒之間的操作是不可預測的，可能會導致競態條件（race condition）和鎖失效的問題，

　　因此，在分布式系統中實作鎖需要使用Redis提供的其他資料結構，如上文提到的基于SETNX命令的實作方式和基于Redlock演算法的實作方式，這些資料結構支持互斥訪問和分布式協作，可以實作分布式系統中的鎖功能，從而保證資料的正確性和一致性，

Q4：分布式鎖可能會失效的場景是什么？

　　在分布式系統中，分布式鎖是用來協調多個行程或執行緒之間對共享資源的訪問的，以保證資料的正確性和一致性，但由于分布式系統的復雜性，分布式鎖可能會出現一些失效的場景，如下：

1. 網路延遲或丟包：由于網路不可靠，分布式系統中的訊息可能會出現延遲或丟失的情況，如果分布式鎖的實作依賴于網路通信，這些問題就可能導致鎖失效，

2. 節點故障：在分布式系統中，節點故障是常見的情況，如果鎖實作依賴于某個節點或實體，當該節點或實體故障時，鎖也可能會失效，

3. 時鐘不同步：分布式系統中的時鐘可能不同步，導致各個節點之間無法達成一致，如果鎖實作依賴于時間戳或過期時間等機制，就可能導致鎖失效，

4. 重入問題：如果一個執行緒已經獲得了分布式鎖，并且在持有鎖的情況下再次嘗試獲取鎖，就會導致死鎖或者其他例外情況，

5. 鎖誤釋放：如果持有鎖的行程或執行緒在釋放鎖時出現例外，比如行程崩潰或者網路故障等，就可能導致鎖沒有正確釋放，其他行程或執行緒無法獲得鎖，從而導致鎖失效，

　　針對上述場景，可以通過一些技術手段來減少分布式鎖失效的風險，比如增加重試機制、使用心跳機制等，但是要注意，分布式鎖的失效場景是很復雜的，需要根據具體的業務場景和系統架構進行綜合分析和解決，

Q5：spring宣告式事務失效場景有哪些？

　　Spring宣告式事務是通過AOP實作的，它的原理是對被@Transactional注解的方法進行代理，然后在方法執行前后進行一些操作，如開啟和提交事務、回滾等，在以下場景中，宣告式事務可能會失效：

1. 事務傳播行為設定不當：Spring宣告式事務默認使用Propagation.REQUIRED傳播行為，如果在呼叫方法的程序中使用了不同的傳播行為，就可能導致事務失效，

2. 例外被吞掉：在方法中捕獲了例外但沒有將其重新拋出或者沒有將其拋給呼叫方，則可能會導致事務無法回滾，

3. 基于介面的代理：如果使用了基于介面的代理，且在實作類中呼叫了自己的另一個方法，那么該方法呼叫將不會被事務管理，

4. 多執行緒情況：當使用多執行緒時，若子執行緒的事務處理方法沒有被@Transactional注解，則可能會導致事務失效，

5. 資料庫引擎不支持事務：如果使用的資料庫引擎不支持事務，則宣告式事務將會失效，

6. 注解放錯位置：如果@Transactional注解放置在類上而不是方法上，則事務將不會生效，

7. 不同的例外型別：如果使用了不同的例外型別，例如RuntimeException而不是Exception，那么事務可能不會回滾，

　　總之，要確保宣告式事務的有效性，應該在呼叫方法上正確使用@Transactional注解，設定正確的傳播行為，避免吞掉例外，同時注意多執行緒和資料庫引擎等因素，

Q6：嵌套事務有什么影響？

　　在Spring中，嵌套事務是一種事務傳播行為，它允許一個事務在另一個事務的背景關系中開啟，形成一個事務嵌套的結構，

　　使用嵌套事務可能會對事務的行為產生一些影響，例如：

1. 回滾行為：當嵌套事務的回滾行為發生時，會影響到外層事務的狀態，如果內層事務回滾，則會導致外層事務也回滾；而外層事務的回滾不會影響到內層事務，

2. 性能開銷：每個嵌套的事務都需要開啟和提交或回滾，這會帶來一些性能開銷，

3. 資料一致性：使用嵌套事務時，需要確保內層事務的提交不會影響到外層事務的資料一致性，否則會導致不一致的結果，

　　因此，在使用嵌套事務時，需要考慮以上因素，并確保在需要使用嵌套事務時，合理地設定事務傳播行為和隔離級別，以保證資料一致性和事務性能，

Q7：springboot怎么進行異步處理？

　　在Spring Boot中進行異步處理有多種方式，其中一些常見的方式包括：

1. 使用@Async注解：通過在方法上添加@Async注解，使方法在異步執行緒中執行，可以使用Spring Boot自帶的執行緒池來管理執行緒，需要在啟動類中添加@EnableAsync注解開啟異步處理，

　　示例代碼：

@Service
public class MyService {

    @Async
    public CompletableFuture<String> asyncMethod() {
        // 異步方法邏輯
        return CompletableFuture.completedFuture("異步方法執行完成");
    }
}

2. 使用CompletableFuture類：CompletableFuture類提供了方便的異步處理方式，可以通過supplyAsync或runAsync方法創建一個異步任務，并指定異步任務的執行邏輯，通過thenApply等方法可以對異步任務的執行結果進行處理，

　　示例代碼：

@Service
public class MyService {

    public CompletableFuture<String> asyncMethod() {
        return CompletableFuture.supplyAsync(() -> {
            // 異步方法邏輯
            return "異步方法執行完成";
        });
    }

}

3. 使用@Scheduled注解：可以使用@Scheduled注解創建定時任務，在任務執行時指定執行邏輯，

　　示例代碼：

@Service
public class MyService {

    @Scheduled(fixedDelay = 1000)
    public void scheduledMethod() {
        // 定時任務執行邏輯
    }

}

　　需要注意的是，使用異步處理可能會引發一些并發問題，例如執行緒安全問題、死鎖問題等，需要根據實際場景進行合理的設計和優化，

Q8：spring注解使用默認執行緒池還是自定義執行緒池？

　　Spring中默認情況下使用的是簡單的執行緒池（SimpleAsyncTaskExecutor），該執行緒池沒有佇列容量限制，每次呼叫都會創建一個新的執行緒，不適用于大規模的并發請求，因此，在實際應用中，應該使用自定義的執行緒池來處理異步任務，

　　可以使用ThreadPoolTaskExecutor或者ConcurrentTaskExecutor來創建自定義的執行緒池，具體選擇哪種執行緒池取決于具體的應用場景，ThreadPoolTaskExecutor是一種基于Java執行緒池的實作，可以靈活地配置核心執行緒數、最大執行緒數、佇列容量等引數；而ConcurrentTaskExecutor是一種基于Java并發包的實作，可以實作更高的并發性能，但是執行緒池的配置選項較少，

　　在使用自定義執行緒池時，可以通過配置ThreadPoolTaskExecutor或者ConcurrentTaskExecutor的相關引數來優化執行緒池的性能，例如配置核心執行緒數、最大執行緒數、佇列容量、執行緒存活時間等引數，同時，在設計應用程式時，還需要根據實際情況合理地使用執行緒池，避免執行緒安全問題和執行緒饑餓等問題的發生，

　　以下是一個簡單的自定義執行緒池的示例代碼：

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.annotation.EnableAsync;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;

import java.util.concurrent.Executor;

@Configuration
@EnableAsync
public class AppConfig {

    @Bean
    public Executor asyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5); // 核心執行緒數
        executor.setMaxPoolSize(10); // 最大執行緒數
        executor.setQueueCapacity(25); // 佇列容量
        executor.setThreadNamePrefix("MyExecutor-"); // 執行緒名前綴
        executor.initialize(); // 初始化執行緒池
        return executor;
    }

}　　

　　上述代碼中，通過@Bean注解將創建的ThreadPoolTaskExecutor類實體化為Spring的Bean，并使用@EnableAsync注解啟用異步處理功能，在創建執行緒池時，可以通過setCorePoolSize、setMaxPoolSize、setQueueCapacity等方法設定執行緒池的核心執行緒數、最大執行緒數和佇列容量等引數，并通過setThreadNamePrefix方法設定執行緒名前綴，最后通過initialize方法初始化執行緒池，并將執行緒池回傳為一個Executor型別的Bean，

　　使用上述自定義執行緒池的示例：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.Executor;

@Service
public class MyService {

    @Autowired
    private Executor asyncExecutor; // 注入自定義執行緒池

    public CompletableFuture<String> asyncMethod() {
        return CompletableFuture.supplyAsync(() -> {
            // 異步方法邏輯
            return "異步方法執行完成";
        }, asyncExecutor); // 指定使用自定義執行緒池
    }

}

　　在上述示例代碼中，通過@Autowired注解將自定義的執行緒池注入到MyService類中，并在異步方法中通過supplyAsync方法指定使用自定義執行緒池來執行異步任務，

Q9：說一下常見的幾個執行緒池？

　　在Java中，執行緒池是一種重要的并發編程工具，可以避免創建和銷毀執行緒帶來的性能開銷和資源浪費，提高應用程式的性能和穩定性，Java標準庫中提供了許多不同型別的執行緒池，常見的幾個執行緒池包括：

1. FixedThreadPool：固定執行緒池，所有任務都在同一個固定大小的執行緒池中執行，適用于需要保證并發執行緒數不超過指定數量的場景，

2. CachedThreadPool：快取執行緒池，可以動態調整執行緒數，適用于需要處理大量短時間任務的場景，

3. SingleThreadExecutor：單執行緒池，只有一個執行緒在執行任務，適用于需要按順序執行任務或保證任務的執行緒安全性的場景，

4. ScheduledThreadPool：調度執行緒池，支持按照指定的時間間隔或者時間點執行任務，適用于需要按照特定時間執行任務的場景，

5. WorkStealingPool：作業竊取執行緒池，可以動態調整執行緒數并支持執行緒間任務竊取，適用于需要處理大量短時間任務且任務之間存在依賴關系的場景，

6. ForkJoinPool：分治執行緒池，支持任務拆分和合并，適用于需要處理大量并行計算任務的場景，

　　這些執行緒池都有各自的優點和適用場景，在實際應用中需要根據具體的需求選擇合適的執行緒池，同時，在使用執行緒池時，還需要合理地配置執行緒池引數，以充分利用計算機的資源，提高執行緒池的執行效率，

Q10：講下核心執行緒數，最大執行緒數，超時時間，等待佇列等

　　在Java中，執行緒池是一種重要的并發編程工具，常見的執行緒池引數包括：

1. 核心執行緒數（corePoolSize）：指執行緒池中最少保持的活動執行緒數，當執行緒池中的執行緒數小于該值時，新任務將會創建新的執行緒來處理，對于FixedThreadPool和SingleThreadExecutor，核心執行緒數即為執行緒池的大小；對于其他執行緒池，核心執行緒數將會一直保持活動狀態，直到執行緒池關閉，

2. 最大執行緒數（maximumPoolSize）：指執行緒池中最大可創建的執行緒數，當執行緒池中的執行緒數達到該值時，新任務將會被阻塞，直到有空閑執行緒可用，對于FixedThreadPool，最大執行緒數即為執行緒池的大小；對于其他執行緒池，最大執行緒數可以根據實際需求進行配置，

3. 超時時間（keepAliveTime）：指執行緒池中空閑執行緒的存活時間，當執行緒池中的執行緒數超過核心執行緒數時，空閑執行緒將會在指定時間內被回收，對于其他執行緒池，如果空閑執行緒超過該時間，也會被回收，

4. 等待佇列（workQueue）：指執行緒池中的任務佇列，用于存放等待執行的任務，執行緒池中的任務將會依次被放入該佇列中，直到有空閑執行緒可用，對于FixedThreadPool和SingleThreadExecutor，任務佇列為空；對于其他執行緒池，任務佇列可以根據實際需求進行配置，常見的佇列型別包括有界佇列（ArrayBlockingQueue、LinkedBlockingQueue）和無界佇列（SynchronousQueue），

　　這些執行緒池引數都會對執行緒池的性能和行為產生影響，需要根據實際應用場景進行合理的配置，例如，如果任務的執行時間較長，可以適當增加執行緒池的最大執行緒數，以避免任務阻塞；如果任務的數量較多，可以增加等待佇列的大小，以緩解執行緒池的壓力，同時，還需要注意執行緒池的可擴展性和性能，以避免執行緒池成為應用程式的瓶頸，

暫未結束，下篇見~

標籤：其他

上一篇：JavaSE筆記之注解和反射（含案例代碼）

下一篇：你可能不那么知道的Tomcat生命周期管理 | 博學谷狂野架構師