摘要：不同于個人面經，這份面經具有普適性。我在前面的文章中也提到了應該怎么做自我介紹與項目介紹，詳情可以查看這篇文章備戰春招秋招系列初出茅廬的程序員該如何準備面試。是建立連接時使用的握手信號。它表示確認發來的數據已經接受無誤。

該文已加入開源文檔：JavaGuide（一份涵蓋大部分Java程序員所需要掌握的核心知識）。地址:https://github.com/Snailclimb...

【強烈推薦！非廣告！】阿里云雙11褥羊毛活動：https://m.aliyun.com/act/team... 差不多一折，不過僅限阿里云新人購買，不是新人的朋友自己找方法買哦！

系列文章：

【備戰春招/秋招系列1】程序員的簡歷就該這樣寫

【備戰春招/秋招系列2】初出茅廬的程序員該如何準備面試？

【備戰春招/秋招系列3】Java程序員必備書單

這是我總結的美團面經的基礎篇，后面還有進階和終結篇哦！下面只是我從很多份美團面經中總結的在面試中一些常見的問題。不同于個人面經，這份面經具有普適性。每次面試必備的自我介紹、項目介紹這些東西，大家可以自己私下好好思考。我在前面的文章中也提到了應該怎么做自我介紹與項目介紹，詳情可以查看這篇文章：【備戰春招/秋招系列2】初出茅廬的程序員該如何準備面試？。

正確答案：11.

考察知識點：邏輯運算符與（&和&&）或（|和||）

&和&&：

共同點：它們都表示運算符的兩邊都是true時，結果為true；

不同點: & 表示在運算時兩邊都會計算，然后再判斷；&&表示先運算符號左邊的東西，然后判斷是否為true，是true就繼續運算右邊的然后判斷并輸出，是false就停下來直接輸出不會再運行后面的東西。

|和||：

共同點：它們都表示運算符的兩邊任意一邊為true，結果為true，兩邊都不是true，結果就為false；

不同點：| 表示兩邊都會運算，然后再判斷結果；|| 表示先運算符號左邊的東西，然后判斷是否為true，是true就停下來直接輸出不會再運行后面的東西，是false就繼續運算右邊的然后判斷并輸出。

回到本題：

3 | 9=0011（二進制） | 1001（二進制）=1011（二進制）=11（十進制）

轉發是服務器行為，重定向是客戶端行為。

轉發（Forword） 通過RequestDispatcher對象的forward（HttpServletRequest request,HttpServletResponse response）方法實現的。RequestDispatcher 可以通過HttpServletRequest 的 getRequestDispatcher()方法獲得。例如下面的代碼就是跳轉到 login_success.jsp 頁面。

request.getRequestDispatcher("login_success.jsp").forward(request, response);

重定向（Redirect） 是利用服務器返回的狀態嗎來實現的?？蛻舳藶g覽器請求服務器的時候，服務器會返回一個狀態碼。服務器通過HttpServletRequestResponse的setStatus(int status)方法設置狀態碼。如果服務器返回301或者302，則瀏覽器會到新的網址重新請求該資源。

從地址欄顯示來說: forward是服務器請求資源,服務器直接訪問目標地址的URL,把那個URL的響應內容讀取過來,然后把這些內容再發給瀏覽器.瀏覽器根本不知道服務器發送的內容從哪里來的,所以它的地址欄還是原來的地址. redirect是服務端根據邏輯,發送一個狀態碼,告訴瀏覽器重新去請求那個地址.所以地址欄顯示的是新的URL.

從數據共享來說: forward:轉發頁面和轉發到的頁面可以共享request里面的數據. redirect:不能共享數據.

從運用地方來說: forward:一般用于用戶登陸的時候,根據角色轉發到相應的模塊. redirect:一般用于用戶注銷登陸時返回主頁面和跳轉到其它的網站等

從效率來說: forward:高. redirect:低.

圖解（圖片來源：《圖解HTTP》）：

總體來說分為以下幾個過程:

DNS解析

TCP連接

發送HTTP請求

服務器處理請求并返回HTTP報文

瀏覽器解析渲染頁面

連接結束

具體可以參考下面這篇文章：

https://segmentfault.com/a/1190000006879700

為了準確無誤地把數據送達目標處，TCP協議采用了三次握手策略。

漫畫圖解：

圖片來源：《圖解HTTP》

簡單示意圖：

客戶端–發送帶有 SYN 標志的數據包–一次握手–服務端

服務端–發送帶有 SYN/ACK 標志的數據包–二次握手–客戶端

客戶端–發送帶有帶有 ACK 標志的數據包–三次握手–服務端

三次握手的目的是建立可靠的通信信道，說到通訊，簡單來說就是數據的發送與接收，而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的。

第一次握手：Client 什么都不能確認；Server 確認了對方發送正常，自己接收正常。

第二次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己接收正常，對方發送正常

第三次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己發送、接收正常，對方發送接收正常

所以三次握手就能確認雙發收發功能都正常，缺一不可。

接收端傳回發送端所發送的 SYN 是為了告訴發送端，我接收到的信息確實就是你所發送的信號了。

SYN 是 TCP/IP 建立連接時使用的握手信號。在客戶機和服務器之間建立正常的 TCP 網絡連接時，客戶機首先發出一個 SYN 消息，服務器使用 SYN-ACK 應答表示接收到了這個消息，最后客戶機再以 ACK(Acknowledgement[漢譯：確認字符 ,在數據通信傳輸中，接收站發給發送站的一種傳輸控制字符。它表示確認發來的數據已經接受無誤。 ]）消息響應。這樣在客戶機和服務器之間才能建立起可靠的TCP連接，數據才可以在客戶機和服務器之間傳遞。

雙方通信無誤必須是兩者互相發送信息都無誤。傳了 SYN，證明發送方（主動關閉方）到接收方（被動關閉方）的通道沒有問題，但是接收方到發送方的通道還需要 ACK 信號來進行驗證。

斷開一個 TCP 連接則需要“四次揮手”：

客戶端-發送一個 FIN，用來關閉客戶端到服務器的數據傳送

服務器-收到這個 FIN，它發回一 個 ACK，確認序號為收到的序號加1 。和 SYN 一樣，一個 FIN 將占用一個序號

服務器-關閉與客戶端的連接，發送一個FIN給客戶端

客戶端-發回 ACK 報文確認，并將確認序號設置為收到序號加1

任何一方都可以在數據傳送結束后發出連接釋放的通知，待對方確認后進入半關閉狀態。當另一方也沒有數據再發送的時候，則發出連接釋放通知，對方確認后就完全關閉了TCP連接。

舉個例子：A 和 B 打電話，通話即將結束后，A 說“我沒啥要說的了”，B回答“我知道了”，但是 B 可能還會有要說的話，A 不能要求 B 跟著自己的節奏結束通話，于是 B 可能又巴拉巴拉說了一通，最后 B 說“我說完了”，A 回答“知道了”，這樣通話才算結束。

上面講的比較概括，推薦一篇講的比較細致的文章：https://blog.csdn.net/qzcsu/article/details/72861891

參考：https://blog.csdn.net/guoweimelon/article/details/50858597

IP地址是指互聯網協議地址（Internet Protocol Address）IP Address的縮寫。IP地址是IP協議提供的一種統一的地址格式，它為互聯網上的每一個網絡和每一臺主機分配一個邏輯地址，以此來屏蔽物理地址的差異。

MAC 地址又稱為物理地址、硬件地址，用來定義網絡設備的位置。網卡的物理地址通常是由網卡生產廠家寫入網卡的，具有全球唯一性。MAC地址用于在網絡中唯一標示一個網卡，一臺電腦會有一或多個網卡，每個網卡都需要有一個唯一的MAC地址。

HTTP請求報文主要由請求行、請求頭部、請求正文3部分組成

HTTP響應報文主要由狀態行、響應頭部、響應正文3部分組成

詳細內容可以參考：https://blog.csdn.net/a19881029/article/details/14002273

為什么要使用索引？

通過創建唯一性索引，可以保證數據庫表中每一行數據的唯一性。

可以大大加快 數據的檢索速度（大大減少的檢索的數據量）, 這也是創建索引的最主要的原因。

幫助服務器避免排序和臨時表

將隨機IO變為順序IO

可以加速表和表之間的連接，特別是在實現數據的參考完整性方面特別有意義。

索引這么多優點，為什么不對表中的每一個列創建一個索引呢？

當對表中的數據進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了數據的維護速度。

索引需要占物理空間，除了數據表占數據空間之外，每一個索引還要占一定的物理空間，如果要建立聚簇索引，那么需要的空間就會更大。

創建索引和維護索引要耗費時間，這種時間隨著數據量的增加而增加。

索引是如何提高查詢速度的？

將無序的數據變成相對有序的數據（就像查目錄一樣）

說一下使用索引的注意事項

避免 where 子句中對宇段施加函數，這會造成無法命中索引。

在使用InnoDB時使用與業務無關的自增主鍵作為主鍵，即使用邏輯主鍵，而不要使用業務主鍵。

將打算加索引的列設置為 NOT NULL ，否則將導致引擎放棄使用索引而進行全表掃描

刪除長期未使用的索引，不用的索引的存在會造成不必要的性能損耗 MySQL 5.7 可以通過查詢 sys 庫的 chema_unused_indexes 視圖來查詢哪些索引從未被使用

在使用 limit offset 查詢緩慢時，可以借助索引來提高性能

Mysql索引主要使用的哪兩種數據結構？

哈希索引：對于哈希索引來說，底層的數據結構就是哈希表，因此在絕大多數需求為單條記錄查詢的時候，可以選擇哈希索引，查詢性能最快；其余大部分場景，建議選擇BTree索引。

BTree索引：Mysql的BTree索引使用的是B樹中的B+Tree。但對于主要的兩種存儲引擎（MyISAM和InnoDB）的實現方式是不同的。

更多關于索引的內容可以查看我的這篇文章：【思維導圖-索引篇】搞定數據庫索引就是這么簡單

什么是覆蓋索引?

如果一個索引包含（或者說覆蓋）所有需要查詢的字段的值，我們就稱
之為“覆蓋索引”。我們知道在InnoDB存儲引擎中，如果不是主鍵索引，葉子節點存儲的是主鍵+列值。最終還是要“回表”，也就是要通過主鍵再查找一次,這樣就會比較慢。覆蓋索引就是把要查詢出的列和索引是對應的，不做回表操作！

進程與線程的區別是什么？

線程與進程相似，但線程是一個比進程更小的執行單位。一個進程在其執行的過程中可以產生多個線程。與進程不同的是同類的多個線程共享同一塊內存空間和一組系統資源，所以系統在產生一個線程，或是在各個線程之間作切換工作時，負擔要比進程小得多，也正因為如此，線程也被稱為輕量級進程。另外，也正是因為共享資源，所以線程中執行時一般都要進行同步和互斥?？偟膩碚f，進程和線程的主要差別在于它們是不同的操作系統資源管理方式。

進程間的幾種通信方式說一下？

管道（pipe）：管道是一種半雙工的通信方式，數據只能單向流動，而且只能在具有血緣關系的進程間使用。進程的血緣關系通常指父子進程關系。管道分為pipe（無名管道）和fifo（命名管道）兩種，有名管道也是半雙工的通信方式，但是它允許無親緣關系進程間通信。

信號量（semophore）：信號量是一個計數器，可以用來控制多個進程對共享資源的訪問。它通常作為一種鎖機制，防止某進程正在訪問共享資源時，其他進程也訪問該資源。因此，主要作為進程間以及同一進程內不同線程之間的同步手段。

消息隊列（message queue）：消息隊列是由消息組成的鏈表，存放在內核中 并由消息隊列標識符標識。消息隊列克服了信號傳遞信息少，管道只能承載無格式字節流以及緩沖區大小受限等缺點。消息隊列與管道通信相比，其優勢是對每個消息指定特定的消息類型，接收的時候不需要按照隊列次序，而是可以根據自定義條件接收特定類型的消息。

信號（signal）：信號是一種比較復雜的通信方式，用于通知接收進程某一事件已經發生。

共享內存（shared memory）：共享內存就是映射一段能被其他進程所訪問的內存，這段共享內存由一個進程創建，但多個進程都可以訪問，共享內存是最快的IPC方式，它是針對其他進程間的通信方式運行效率低而專門設計的。它往往與其他通信機制，如信號量配合使用，來實現進程間的同步和通信。

套接字（socket）：套接口也是一種進程間的通信機制，與其他通信機制不同的是它可以用于不同及其間的進程通信。

線程間的幾種通信方式知道不？

1、鎖機制

互斥鎖：提供了以排它方式阻止數據結構被并發修改的方法。

讀寫鎖：允許多個線程同時讀共享數據，而對寫操作互斥。

條件變量：可以以原子的方式阻塞進程，直到某個特定條件為真為止。對條件測試是在互斥鎖的保護下進行的。條件變量始終與互斥鎖一起使用。

2、信號量機制：包括無名線程信號量與有名線程信號量

3、信號機制：類似于進程間的信號處理。

線程間通信的主要目的是用于線程同步，所以線程沒有象進程通信中用于數據交換的通信機制。

簡單來說使用單例模式可以帶來下面幾個好處:

對于頻繁使用的對象，可以省略創建對象所花費的時間，這對于那些重量級對象而言，是非?？捎^的一筆系統開銷；

由于 new 操作的次數減少，因而對系統內存的使用頻率也會降低，這將減輕 GC 壓力，縮短 GC 停頓時間。

懶漢式(雙重檢查加鎖版本)

public class Singleton {

    //volatile保證，當uniqueInstance變量被初始化成Singleton實例時，多個線程可以正確處理uniqueInstance變量
    private volatile static Singleton uniqueInstance;
    private Singleton() {
    }
    public static Singleton getInstance() {
       //檢查實例，如果不存在，就進入同步代碼塊
        if (uniqueInstance == null) {
            //只有第一次才徹底執行這里的代碼
            synchronized(Singleton.class) {
               //進入同步代碼塊后，再檢查一次，如果仍是null，才創建實例
                if (uniqueInstance == null) {
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

靜態內部類方式

靜態內部實現的單例是懶加載的且線程安全。

只有通過顯式調用 getInstance 方法時，才會顯式裝載 SingletonHolder 類，從而實例化 instance（只有第一次使用這個單例的實例的時候才加載，同時不會有線程安全問題）。

public class Singleton {  
    private static class SingletonHolder {  
    private static final Singleton INSTANCE = new Singleton();  
    }  
    private Singleton (){}  
    public static final Singleton getInstance() {  
    return SingletonHolder.INSTANCE;  
    }  
}   

在 Spring 中，那些組成應用程序的主體及由 Spring IOC 容器所管理的對象，被稱之為 bean。簡單地講，bean 就是由 IOC 容器初始化、裝配及管理的對象，除此之外，bean 就與應用程序中的其他對象沒有什么區別了。而 bean 的定義以及 bean 相互間的依賴關系將通過配置元數據來描述。

Spring中的bean默認都是單例的，這些單例Bean在多線程程序下如何保證線程安全呢？ 例如對于Web應用來說，Web容器對于每個用戶請求都創建一個多帶帶的Sevlet線程來處理請求，引入Spring框架之后，每個Action都是單例的，那么對于Spring托管的單例Service Bean，如何保證其安全呢？ Spring的單例是基于BeanFactory也就是Spring容器的，單例Bean在此容器內只有一個，Java的單例是基于 JVM，每個 JVM 內只有一個實例。

Spring的bean的生命周期以及更多內容可以查看：一文輕松搞懂Spring中bean的作用域與生命周期

事務傳播行為（為了解決業務層方法之間互相調用的事務問題）：
當事務方法被另一個事務方法調用時，必須指定事務應該如何傳播。例如：方法可能繼續在現有事務中運行，也可能開啟一個新事務，并在自己的事務中運行。在TransactionDefinition定義中包括了如下幾個表示傳播行為的常量：

支持當前事務的情況：

TransactionDefinition.PROPAGATION_REQUIRED： 如果當前存在事務，則加入該事務；如果當前沒有事務，則創建一個新的事務。

TransactionDefinition.PROPAGATION_SUPPORTS： 如果當前存在事務，則加入該事務；如果當前沒有事務，則以非事務的方式繼續運行。

TransactionDefinition.PROPAGATION_MANDATORY： 如果當前存在事務，則加入該事務；如果當前沒有事務，則拋出異常。（mandatory：強制性）

不支持當前事務的情況：

TransactionDefinition.PROPAGATION_REQUIRES_NEW： 創建一個新的事務，如果當前存在事務，則把當前事務掛起。

TransactionDefinition.PROPAGATION_NOT_SUPPORTED： 以非事務方式運行，如果當前存在事務，則把當前事務掛起。

TransactionDefinition.PROPAGATION_NEVER： 以非事務方式運行，如果當前存在事務，則拋出異常。

其他情況：

TransactionDefinition.PROPAGATION_NESTED： 如果當前存在事務，則創建一個事務作為當前事務的嵌套事務來運行；如果當前沒有事務，則該取值等價于TransactionDefinition.PROPAGATION_REQUIRED。

TransactionDefinition 接口中定義了五個表示隔離級別的常量：

TransactionDefinition.ISOLATION_DEFAULT: 使用后端數據庫默認的隔離級別，Mysql 默認采用的 REPEATABLE_READ隔離級別 Oracle 默認采用的 READ_COMMITTED隔離級別.

TransactionDefinition.ISOLATION_READ_UNCOMMITTED: 最低的隔離級別，允許讀取尚未提交的數據變更，可能會導致臟讀、幻讀或不可重復讀

TransactionDefinition.ISOLATION_READ_COMMITTED: 允許讀取并發事務已經提交的數據，可以阻止臟讀，但是幻讀或不可重復讀仍有可能發生

TransactionDefinition.ISOLATION_REPEATABLE_READ: 對同一字段的多次讀取結果都是一致的，除非數據是被本身事務自己所修改，可以阻止臟讀和不可重復讀，但幻讀仍有可能發生。

TransactionDefinition.ISOLATION_SERIALIZABLE: 最高的隔離級別，完全服從ACID的隔離級別。所有的事務依次逐個執行，這樣事務之間就完全不可能產生干擾，也就是說，該級別可以防止臟讀、不可重復讀以及幻讀。但是這將嚴重影響程序的性能。通常情況下也不會用到該級別。

客戶端發送請求-> 前端控制器 DispatcherServlet 接受客戶端請求 -> 找到處理器映射 HandlerMapping 解析請求對應的 Handler-> HandlerAdapter 會根據 Handler 來調用真正的處理器開處理請求，并處理相應的業務邏輯 -> 處理器返回一個模型視圖 ModelAndView -> 視圖解析器進行解析 -> 返回一個視圖對象->前端控制器 DispatcherServlet 渲染數據（Moder）->將得到視圖對象返回給用戶

關于 SpringMVC 原理更多內容可以查看我的這篇文章：SpringMVC 工作原理詳解

過了秋招挺長一段時間了，說實話我自己也忘了如何簡要概括 Spring AOP IOC 實現原理，就在網上找了一個較為簡潔的答案，下面分享給各位。

IOC: 控制反轉也叫依賴注入。IOC利用java反射機制，AOP利用代理模式。IOC 概念看似很抽象，但是很容易理解。說簡單點就是將對象交給容器管理，你只需要在spring配置文件中配置對應的bean以及設置相關的屬性，讓spring容器來生成類的實例對象以及管理對象。在spring容器啟動的時候，spring會把你在配置文件中配置的bean都初始化好，然后在你需要調用的時候，就把它已經初始化好的那些bean分配給你需要調用這些bean的類。

AOP： 面向切面編程。（Aspect-Oriented Programming） 。AOP可以說是對OOP的補充和完善。OOP引入封裝、繼承和多態性等概念來建立一種對象層次結構，用以模擬公共行為的一個集合。實現AOP的技術，主要分為兩大類：一是采用動態代理技術，利用截取消息的方式，對該消息進行裝飾，以取代原有對象行為的執行；二是采用靜態織入的方式，引入特定的語法創建“方面”，從而使得編譯器可以在編譯期間織入有關“方面”的代碼，屬于靜態代理。

你若盛開，清風自來。 歡迎關注我的微信公眾號：“Java面試通關手冊”，一個有溫度的微信公眾號。公眾號后臺回復關鍵字“1”，可以免費獲取一份我精心準備的小禮物哦！