眾安保險面試難不難，我們一起瞧瞧去！

作者：磊哥 2025-01-03 14:45:49

服務降級以及服務熔斷和服務限流都不是最優解，因為以上所有操作都是以犧牲用戶體驗為前提的，而最優的解決方案，應該是讓用戶不受影響，讓用戶無感知的使用程序才對。

1.說一下Java內存模型？

注意，當問到 Java 內存模型的時候，不要和 JVM 內存布局（JVM 運行時數據區域）搞混了，這塊問的不是 JVM 內存的布局是啥，而是 Java 內存模型，Java Memory Model，簡稱 JMM。

Java 內存模型是用來定義 Java 線程和內存之間的操作規范的，目的是解決多線程正確執行的問題。Java 內存模型規范的定義確保了多線程程序的可見性、有序性和原子性，從而保證了線程之間正確的交互和數據一致性。Java 內存模型主要包括以下內容：

主內存（Main Memory）：所有線程共享的內存區域，包含了對象的字段、方法和運行時常量池等數據。
工作內存（Working Memory）：每個線程擁有自己的工作內存，用于存儲主內存中的數據的副本。線程只能直接操作工作內存中的數據。
內存間交互操作：線程通過讀取和寫入操作與主內存進行交互。讀操作將數據從主內存復制到工作內存，寫操作將修改后的數據刷新到主內存。
原子性（Atomicity）：JMM 保證基本數據類型（如 int、long）的讀寫操作具有原子性，即不會被其他線程干擾，保證操作的完整性。
可見性（Visibility）：JMM 確保一個線程對共享變量的修改對其他線程可見。這意味著一個線程在工作內存中修改了數據后，必須將最新的數據刷新到主內存，以便其他線程可以讀取到更新后的數據。
有序性（Ordering）：JMM 保證程序的執行順序按照一定的規則進行，不會出現隨機的重排序現象。這包括了編譯器重排序、處理器重排序和內存重排序等。

Java 內存模型通過以上規則和語義，提供了一種統一的內存訪問方式，使得多線程程序的行為可預測、可理解，并幫助開發者編寫正確和高效的多線程代碼。開發者可以利用 JMM 提供的同步機制（如關鍵字 volatile、synchronized、Lock 等）來實現線程之間的同步和通信，以確保線程安全和數據一致性。

內存模型的簡單執行示例圖如下：

圖片

2.List、Set、Map的區別？

List、Set 和 Map 都是常見的集合接口，用于存儲和操作數據，它們的區別如下：

List 是有序的集合，允許重復元素，可以按索引訪問。它的常見實現類有 ArrayList、LinkedList 和 Vector。
Set 是無序的集合，不允許重復元素。它的常見實現類有 HashSet、TreeSet 和 LinkedHashSet。
Map 是鍵值對的映射集合，鍵不允許重復，值可以重復。它的常見實現類有 HashMap、TreeMap 和 LinkedHashMap。

3.介紹一下設計模式？

當聊到設計模式時，可以舉一些常見的設計模式，以及這些設計模式的具體應用，比如以下這些：

工廠模式（Factory Pattern）：工廠模式是一種創建型設計模式，它提供了一種創建對象的方式，使得應用程序可以更加靈活和可維護。比如在 Spring 中，FactoryBean 就是一個工廠模式的實現，使用它的工廠模式就可以創建出來其他的 Bean 對象。
單例模式（Singleton Pattern）：單例模式是一種創建型設計模式，它保證一個類只有一個實例，并提供了一個全局訪問點。比如在 Spring 中，所以的 Bean 默認是單例的，這意味著每個 Bean 只會被創建一次，并且可以在整個應用程序中共享。
代理模式模式（Proxy Pattern）：代理模式是一種結構型設計模式，它允許開發人員在不修改原有代碼的情況下，向應用程序中添加新的功能。比如在 Spring AOP（面向切面編程）就是使用代理模式的實現，它允許開發人員在方法調用前后執行一些自定義的操作，比如日志記錄、性能監控等。
模板方法模式（Template Pattern）：模板方法模式是最常用的設計模式之一，它是指定義一個操作算法的骨架，而將一些步驟的實現延遲到子類中去實現，使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。此模式是基于繼承的思想實現代碼復用的。比如在 MyBatis 中的典型代表 BaseExecutor，在 MyBatis 中 BaseExecutor 實現了大部分SQL 執行的邏輯。
觀察者模式（Observer Pattern）：定義了一種一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴于它的對象都會得到通知并自動更新。比如事件驅動、消息傳遞等功能時，可以使用觀察者模式，例如 Spring Event 事件機制。
適配器模式（Adapter Pattern）：適配器模式是一種結構型設計模式，它允許開發人員將一個類的接口轉換成另一個類的接口，以滿足客戶端的需求。在 Spring 中，適配器模式常用于將不同類型的對象轉換成統一的接口，比如將 Servlet API 轉換成 Spring MVC 的控制器接口。

4.MySQL存儲結構？

在 MySQL 默認的存儲引擎 InnoDB 中，所有數據都被邏輯地存放在一個空間內，稱為表空間（tablespace），而表空間由段（sengment）、區（extent）、頁（page）組成。

圖片

其中：

表空間（tablespace）是一組邏輯文件，用于存儲表和索引數據。它是 InnoDB 存儲引擎的基本組織單位，可以看作是一個獨立的存儲區域。
段（segment）是表空間的子單位，它是邏輯上連續的數據塊，存儲了一組數據頁。段可以是用于存儲表數據的數據段，也可以是用于存儲索引的索引段。
區（extent）是段的子單位，它是一組連續的物理頁，通常是 64 個連續的頁。在一個區中，可以存儲一個或多個數據頁。
頁（page）是 InnoDB 存儲數據的最小單位，通常為 16KB 大小。每個頁都有一個唯一的標識符，用于在磁盤和內存中定位和管理數據。InnoDB 使用頁來存儲表的行數據和索引數據。

表空間包含多個段，段包含多個區，區包含多個頁。這種層次結構幫助 InnoDB 有效地管理存儲空間，并提供高性能和可靠性的數據訪問。

舉一個例子，假設表空間就是整個書架，段是書架的每一層，區是每一層上的每一個格子，頁是每個格子里面放的一頁紙。這種層次結構讓 MySQL InnoDB 能夠更有效地管理和訪問數據，就像你可以根據書的編號和位置快速找到你想要的書籍一樣。

5.索引失效的場景？

常見的索引失效場景有以下這些：

未遵循最左匹配原則
使用列運算
使用函數方法
類型轉換
使用 is not null
錯誤的模糊匹配，使用右 % 開始查詢。

具體內容請參考：https://www.javacn.site/interview/mysql/indexinvalid.html

6.為什么使用函數索引會失效？

使用函數導致索引失效的原因，是因為函數會對索引列的值進行計算或轉換，導致 MySQL 無法直接匹配索引中的數據，從而無法使用索引來進行查詢優化了。

比如以下索引結構：

圖片

如果你的 SQL 語句條件用的是 where t_modified='2018-7-1' 的話，引擎就會按照上面綠色箭頭的路線，快速定位到 t_modified='2018-7-1' 需要的結果。實際上，B+ 樹提供的這個快速定位能力，來源于同一層兄弟節點的有序性。

但是，如果計算 month() 函數的話，你會看到傳入 7 的時候，在樹的第一層就不知道該怎么辦了。

也就是說，對索引字段做函數操作，可能會破壞索引值的有序性，因此優化器就決定放棄走樹搜索功能。

7.Spring事務有哪兩種？

Spring 提供了兩種事務：

編程式事務
聲明式事務

它們的實現如下。

7.1 編程式事務

@RestController
public class UserController {
    // 事務管理器
    @Resource
    private DataSourceTransactionManager dataSourceTransactionManager;
    // 定義事務屬性
    @Resource
    private TransactionDefinition transactionDefinition;
    @Resource
    private UserService userService;

    @RequestMapping("/sava")
    public Object save(User user) {
        // 開啟事務
        TransactionStatus transactionStatus = dataSourceTransactionManager
                .getTransaction(transactionDefinition);
        // 插入數據庫
        int result = userService.save(user);
        // 提交事務
        dataSourceTransactionManager.commit(transactionStatus);
//        // 回滾事務
//        dataSourceTransactionManager.rollback(transactionStatus);
        return result;
    }
}

7.2 聲明式事務

聲明式事務的實現非常簡單，只需要給類或方法上添加 @Transactional 注解即可，如下代碼所示：

@RequestMapping("/save")
@Transactional // 添加此注解就是聲明式事務
public Object save(User user) {
  int result = userService.save(user);
  return result;
}

8.@Transactional實現原理？

@Transactional 注解的實現原理是基于 Spring AOP，Spring AOP 又是基于動態代理（模式）的實現。

在 Spring 中，@Transactional 注解會通過 AOP 機制生成一個代理 connection 對象，并將其放入 DataSource 實例的某個與 DataSourceTransactionManager 相關的某處容器中。這樣，當開始執行目標方法之前先開啟事務，如果方法正常執行完成則提交事務，如果執行中出現了異常，則會回滾事務。

9.事務如何合并@Transactional修飾的方法？

當一個被 @Transactional 修飾的方法調用另一個被 @Transactional 修飾的方法時，事務會通過事務的傳播機制，也就是 Propagation 屬性的設置來合并事務，事務傳播機制總共有以下 7 種：

Propagation.REQUIRED：默認的事務傳播級別，它表示如果當前存在事務，則加入該事務；如果當前沒有事務，則創建一個新的事務。
Propagation.SUPPORTS：如果當前存在事務，則加入該事務；如果當前沒有事務，則以非事務的方式繼續運行。
Propagation.MANDATORY：（mandatory：強制性）如果當前存在事務，則加入該事務；如果當前沒有事務，則拋出異常。
Propagation.REQUIRES_NEW：表示創建一個新的事務，如果當前存在事務，則把當前事務掛起。也就是說不管外部方法是否開啟事務，Propagation.REQUIRES_NEW 修飾的內部方法會新開啟自己的事務，且開啟的事務相互獨立，互不干擾。
Propagation.NOT_SUPPORTED：以非事務方式運行，如果當前存在事務，則把當前事務掛起。
Propagation.NEVER：以非事務方式運行，如果當前存在事務，則拋出異常。
Propagation.NESTED：如果當前存在事務，則創建一個事務作為當前事務的嵌套事務來運行；如果當前沒有事務，則該取值等價于 PROPAGATION_REQUIRED。

所以，當你不設置 @Transactional 的 Propagation 屬性時也會合并事務。

而事務的傳播機制 REQUIRED 合并事務是通過事務同步器（TransactionSynchronization）和事務管理器（TransactionManager）來完成的。

事務同步器（TransactionSynchronization）：事務同步器是一個接口，定義了在事務生命周期中的各個階段執行的回調方法。它包括事務開始前、事務提交/回滾后以及事務完成后等方法。事務同步器允許注冊和執行事務相關的操作，如預提交、后提交、回滾等。
事務管理器（TransactionManager）：事務管理器是 Spring 框架中用于管理事務的核心接口。它負責控制事務的開始、提交或回滾，并提供事務的隔離級別和超時等屬性的管理。事務管理器與底層的數據訪問技術（如JDBC、Hibernate、JPA等）進行交互，確保數據操作與事務的一致性。

基于以上概念，REQUIRED 事務傳播機制的實現步驟如下：

當一個帶有 @Transactional(propagation = Propagation.REQUIRED) 注解的方法被調用時，Spring 會檢查當前是否存在一個活動的事務。
如果當前存在一個事務，被調用方法會加入該事務，并與調用方法共享同一個事務。Spring 通過事務同步器（TransactionSynchronization）將被調用方法注冊為事務的一部分。
如果當前不存在事務，事務管理器（TransactionManager）會創建一個新的事務，并將其與被調用方法關聯起來。被調用方法成為這個新事務的第一個參與者。
在事務執行過程中，如果被調用方法拋出異常，則整個事務將被標記為回滾，并觸發事務回滾操作。
在事務執行完成后，事務管理器負責提交整個事務，并觸發事務提交操作。
在事務提交或回滾后，事務同步器會調用事務完成的回調方法，執行相應的清理工作。

通過以上步驟，REQUIRED 事務傳播機制實現了被調用方法與調用方法共享或創建新的事務，并保證在事務執行過程中的一致性和隔離性。

10.Redis數據類型有哪些？

Redis 常用的數據類型有 5 種：String 字符串類型、List 列表類型、Hash 哈希表類型、Set 集合類型、Sorted Set 有序集合類型，如下圖所示：這 5 種常用類型的用途如下：

String：字符串類型，常見使用場景是：存儲 Session 信息、存儲緩存信息（如詳情頁的緩存）、存儲整數信息，可使用 incr 實現整數+1，和使用 decr 實現整數 -1；
List：列表類型，常見使用場景是：實現簡單的消息隊列、存儲某項列表數據；
Hash：哈希表類型，常見使用場景是：存儲 Session 信息、存儲商品的購物車，購物車非常適合用哈希字典表示，使用人員唯一編號作為字典的 key，value 值可以存儲商品的 id 和數量等信息、存儲詳情頁信息；
Set：集合類型，是一個無序并唯一的鍵值集合，它的常見使用場景是：關注功能，比如關注我的人和我關注的人，使用集合存儲，可以保證人員不會重復；
Sorted Set：有序集合類型，相比于 Set 集合類型多了一個排序屬性 score（分值），它的常見使用場景是：可以用來存儲排名信息、關注列表功能，這樣就可以根據關注實現排序展示了。

更多詳情請參考：https://www.javacn.site/interview/redis/types.html

11.Redis如何實現分布式鎖？

Redis 作為一個獨立的三方系統（通常被作為緩存中間件使用），其天生的優勢就是可以作為一個分布式系統（分布式鎖）來使用，如下圖所示：在 Redis 中實現分布式鎖可以使用 SETNX 和 EXPIRE 命令來實現，SETNX 是 "SET if Not eXists" 的縮寫，是一個原子性操作，用于在指定的 key 不存在時設置 key 的值。如果 key 已經存在，SETNX 操作將不做任何事情，返回失敗；如果 key 不存在，SETNX 操作會設置 key 的值，并返回成功。而 EXPIRE 是設置鎖的過期時間的，主要為了防止死鎖的發生，SETNX + EXPIRE 的實現命令如下：

圖片

其中“nx”表示 not exists 不存在則設置 key，“ex 10”表示過期時間為 10 秒，“mylock”值為 key，“lock”值為 value。更多詳情請參考：https://www.javacn.site/interview/redis/redis_lock.html

12.什么時候用RocketMQ？

RocketMQ 是一個分布式消息中間件系統，主要用于解決高吞吐量、低延遲的消息傳遞需求。以下是一些 RocketMQ 的使用場景：

異步消息傳遞：RocketMQ 提供了可靠的異步消息傳遞機制，可以在分布式系統中實現解耦和異步處理。例如，在電商平臺中，當用戶下單成功后，可以使用 RocketMQ 異步地發送訂單信息給庫存系統和支付系統，以提高系統的響應速度和可靠性。
流式數據處理：RocketMQ 支持高吞吐量的消息傳遞，適用于大規模的實時數據處理場景。例如，日志收集和分析系統可以使用 RocketMQ 作為消息中間件，將分布式系統產生的日志實時傳遞給日志處理系統，進行實時監控和分析。
事件驅動架構：RocketMQ 可以作為事件驅動架構的基礎設施，實現系統間的事件通知和響應。例如，微服務架構中的各個服務可以通過 RocketMQ 發送事件消息來通知其他服務進行相應的操作，實現解耦和靈活的系統架構。
分布式事務消息：RocketMQ 提供了事務消息的支持，可以確保分布式系統中的消息發送和業務操作的原子性。在分布式事務場景下，可以使用 RocketMQ 發送事務消息，以確保消息的可靠傳遞和業務操作的一致性。
流量削峰與消息堆積：RocketMQ 支持消息的異步發送和批量發送，可以用于平滑處理系統的流量峰值和消息的堆積情況。例如，在雙11等促銷活動中，可以使用 RocketMQ 來處理大量的訂單請求，避免系統過載和消息丟失。

所以，RocketMQ 在高吞吐量、低延遲、可靠性和擴展性等方面具備優勢，適用于許多分布式系統和大規模數據處理場景。

13.說下RocketMQ和OpenFeign的應用場景？

RocketMQ 應用場景上個問題已經說了。

OpenFeign 的全稱是 Spring Cloud OpenFeign，它是 Spring 官方推出的一種聲明式服務調用和負載均衡組件。它的出現就是為了替代已經進入停更維護狀態的 Feign（Netflix Feign）的。也就是說 OpenFeign（Spring Cloud OpenFeign）是 Feign 的升級版，因為 Feign 停更維護了，所以 Spring 官方需要推出了一個新的新的框架來對 Feign 功能進行升級和擴展。

OpenFeign 應用場景：

微服務架構：OpenFeign 可以在微服務架構中作為服務之間進行通信的客戶端工具。它通過定義接口和注解的方式，使得服務之間的通信變得簡單明了。開發人員只需要定義接口，而無需關注底層的 HTTP 請求和響應處理，從而提高開發效率。
客戶端負載均衡：OpenFeign 集成了負載均衡功能，可以與負載均衡器（如 Ribbon）一起使用，實現客戶端負載均衡。通過配置合適的負載均衡策略，可以將請求分發到多個服務實例上，提高系統的可用性和吞吐量。
服務降級與容錯：OpenFeign 可以集成斷路器（如 Hystrix）來實現服務的降級和容錯處理。當服務不可用或出現異常時，可以定義降級策略，返回預設的響應，以防止故障在整個系統中擴散。

OpenFeign 具體使用可參考：https://juejin.cn/post/7101545210315800612

14.抽象類和接口的區別？

在 Java 中，抽象類和接口是兩種不同的類類型。它們都不能直接實例化，并且它們都是用來定義一些基本的屬性和方法的，但它們有以下幾點不同：

定義不同：定義的關鍵字不同，抽象類是 abstract，而接口是 interface。
方法實現：抽象類可以包含抽象方法和具體方法，而接口只能包含方法聲明（抽象方法）。
方法訪問控制符不同：抽象類無限制，只是抽象類中的抽象方法不能被 private 修飾；而接口有限制，接口默認的是 public 控制符。
實現/繼承數量不同：一個類只能繼承一個抽象類，但可以實現多個接口。
包含變量不同：抽象類可以包含實例變量和靜態變量，而接口只能包含常量。
構造函數不同：抽象類可以有構造函數，而接口不能有構造函數。

更多內容請參考：https://www.javacn.site/interview/basic/abstract-interface.html

15.什么時候用抽象類？什么時候用接口？

接口是用來定義規范的，而抽象類提供了代碼重用。所以，當你要定義規范時可以使用接口，當你要重用代碼時可以使用抽象類。

16.try、catch、finally各有return，會怎么執行？

程序最終會返回 finally 中的 return 值。

因為在 finally 塊中使用了 return 語句，它將會覆蓋在之前的 try 塊或 catch 塊中的返回值。

17.服務宕機時直接降級是最優解嗎？

所以我們可以使用負載均衡與集群化，將服務部署在多臺服務器上，通過負載均衡來分發請求，當其中一臺服務宕機時，負載均衡可以自動將請求轉發給其他正常運行的服務，通過集群化部署，可以提高系統的可靠性和可用性，讓用戶無感知才是最優解。

參考 & 鳴謝

冰河的博客

blog.csdn.net/MariaOzawa/article/details/107363136

責任編輯：武曉燕來源：磊哥和Java

Java 內存模型