某東方面試題Java

mysql默認隔離機制？

1、 可重複讀(Repeatable read)：默認隔離機制,就是在開始讀取數據（事務開啓）時，不再允許修改操作，可避免髒讀、不可重複讀的發生。
　　　　(1)這是MySQL的默認事務隔離級別
　　　　(2)它確保同一事務的多個實例在併發讀取數據時，會看到同樣的數據行
　　　　(3)此級別可能出現的問題——幻讀(Phantom Read)：當用戶讀取某一範圍的數據行時，另一個事務又在該範圍內插入了新行，當用戶再讀取該範圍的數據行時，會發現有新的“幻影” 行
　　　　(4)InnoDB和Falcon存儲引擎通過多版本併發控制(MVCC，Multiversion Concurrency Control)機制解決了該問題
2、讀未提交(Read uncommitted)，一個事務可以讀取另一個未提交事務的數據，最低級別，任何情況都無法保證。
　　　　(1)所有事務都可以看到其他未提交事務的執行結果
　　　　(2)本隔離級別很少用於實際應用，因爲它的性能也不比其他級別好多少
　　　　(3)該級別引發的問題是——髒讀(Dirty Read)：讀取到了未提交的數據
3、讀已提交(Read committed)，一個事務要等另一個事務提交後才能讀取數據，可避免髒讀的發生。
　　　　(1)這是大多數數據庫系統的默認隔離級別（但不是MySQL默認的）
　　　　(2)它滿足了隔離的簡單定義：一個事務只能看見已經提交事務所做的改變
　　　　(3)這種隔離級別出現的問題是——不可重複讀(Nonrepeatable Read)：不可重複讀意味着我們在同一個事務中執行完全相同的select語句時可能看到不一樣的結果。導致這種情況的原因可能有：(1)有一個交叉的事務有新的commit，導致了數據的改變;(2)一個數據庫被多個實例操作時,同一事務的其他實例在該實例處理其間可能會有新的commit

4、串行(Serializable)，是最高的事務隔離級別，在該級別下，事務串行化順序執行，可以避免髒讀、不可重複讀與幻讀。但是這種事務隔離級別效率低下，比較耗數據庫性能，一般不使用。Mysql的默認隔離級別是Repeatable read。
　　　　(1)這是最高的隔離級別
　　　　(2)它通過強制事務排序，使之不可能相互衝突，從而解決幻讀問題。簡言之,它是在每個讀的數據行上加上共享鎖。
　　　　(3)在這個級別，可能導致大量的超時現象和鎖競爭

mysql事務四大特性

• 原子性：不可分割的操作單元，事務中所有操作，要麼全部成功；要麼撤回到執行事務之前的狀態
• 一致性：如果在執行事務之前數據庫是一致的，那麼在執行事務之後數據庫也還是一致的；
• 隔離性：事務操作之間彼此獨立和透明互不影響。事務獨立運行。這通常使用鎖來實現。一個事務處理後的結果，影響了其他事務，那麼其他事務會撤回。事務的100%隔離，需要犧牲速度。
• 持久性：事務一旦提交，其結果就是永久的。即便發生系統故障，也能恢復。

存儲引擎 MyISAM 和 InnoDB區別：

1. InnoDB支持事務，MyISAM不支持。
2. MyISAM適合查詢以及插入爲主的應用，InnoDB適合頻繁修改以及涉及到安全性較高的應用。
3. InnoDB支持外鍵，MyISAM不支持。
4. 從MySQL5.5.5以後，InnoDB是默認引擎。
5. MyISAM支持全文類型索引，而InnoDB不支持全文索引。
6. InnoDB中不保存表的總行數，select count() from table時，InnoDB需要掃描整個表計算有多少行，但MyISAM只需簡單讀出保存好的總行數即可。注：當count()語句包含where條件時MyISAM也需掃描整個表。
7. 對於自增長的字段，InnoDB中必須包含只有該字段的索引，但是在MyISAM表中可以和其他字段一起建立聯合索引。
8. 清空整個表時，InnoDB是一行一行的刪除，效率非常慢。MyISAM則會重建表。MyisAM使用delete語句刪除後並不會立刻清理磁盤空間，需要定時清理，命令：OPTIMIZE table dept;
9. InnoDB支持行鎖（某些情況下還是鎖整表，如 update table set a=1 where user like ‘%lee%’）
10. Myisam創建表生成三個文件：.frm 數據表結構 、 .myd 數據文件 、 .myi 索引文件，Innodb只生成一個 .frm文件，數據存放在ibdata1.log
11. 現在一般都選用InnoDB，主要是MyISAM的全表鎖，讀寫串行問題，併發效率鎖表，效率低，MyISAM對於讀寫密集型應用一般是不會去選用的。
    12. 應用場景：
    • MyISAM不支持事務處理等高級功能，但它提供高速存儲和檢索，以及全文搜索能力。如果應用中需要執行大量的SELECT查詢，那麼MyISAM是更好的選擇。
    • InnoDB用於需要事務處理的應用程序，包括ACID事務支持。如果應用中需要執行大量的INSERT或UPDATE操作，則應該使用InnoDB，這樣可以提高多用戶併發操作的性能。

1、什麼是MVCC

多版本併發控制

原文鏈接：https://blog.csdn.net/fuzhongmin05/article/details/91351933

• LECT時。讀取創建版本<=當前事務版本。刪除版本爲空或>當前事務版本。
• INSERT時，保存當前事務版本爲行的創建版本
• DELETE時，保存當前事務版本爲行的刪除版本
• UPDATE時，插入一條新紀錄。保存當前事務版本爲行創建版本，同一時候保存當前事務版本到原來刪除的行
• 通過MVCC，儘管每行記錄都須要額外的存儲空間，很多其它的行檢查工作以及一些額外的維護工作。但能夠降低鎖的使用，大多數讀操作都不用加鎖，讀數據操作非常easy，性能非常好，而且也能保證僅僅會讀取到符合標準的行。也僅僅鎖住必要行。

nginx常用命令

nginx -s quit         優雅停止nginx，有連接時會等連接請求完成再殺死worker進程  
nginx -s reload     優雅重啓，並重新載入配置文件nginx.conf
nginx -s reopen     重新打開日誌文件，一般用於切割日誌
nginx -v            查看版本  
nginx -t            檢查nginx的配置文件
nginx -h            查看幫助信息

nginx -V 詳細版本信息，包括編譯參數
nginx -c filename 指定配置文件

docker是什麼

你的業務代碼和部署環境打包在一起，保證了各測試，預發，生產環境下的部署一致性，而且方便擴容

1.更高效的利用系統資源
2.更快速的啓動時間
3.一致的運行環境
4.持續交付和部署
5.更輕鬆的遷移、擴容

##搜索倉庫MySQL鏡像 docker search mysql

–filter=stars=600：只顯示 starts>=600 的鏡像 docker search --filter=stars=600 mysql

–no-trunc 顯示鏡像完整 DESCRIPTION 描述 docker search --no-trunc mysql

–automated ：只列出 AUTOMATED=OK 的鏡像 docker search --automated mysql

##下載Redis官方最新鏡像，相當於：docker pull redis:latest docker pull redis
##下載倉庫所有Redis鏡像 docker pull -a redis
##下載私人倉庫鏡像 docker pull bitnami/redis

消息隊列、消息代理和消息中間件的區別和聯繫

中間件(Middleware)

首先就要說什麼是中間件?我的理解是：
中間件是幫助應用程序與其他應用程序、網絡、硬件、操作系統交互或通信的軟件。
換句更簡潔的話：「將具體業務和底層邏輯解耦的軟件」。其實符合中間件的軟件範疇非常寬，日常用的Redis、Nginx、Zookeeper、Memcached等等都是「中間件」。所謂的「中間」是相對於架構體系內的，它不涉及具體的業務邏輯也不涉及底層的硬件邏輯，用於用戶數據交換和管理，能夠起到「中介」的作用，這就是中間件。

1. 數據庫中間件
   當項目很小的時候，直接使用編程語言下的數據庫驅動操作數據庫就可以了，有些開發會用ORM的方式操作數據庫：這是夠用的。
   但隨着業務發展，數據量和讀寫QPS越來越高，主從模式的MySQL實例壓力越來越大，單純的對服務器硬件升級已經無法滿足生產環境的需要。在我司不成文的習慣是單表不要超過5千萬條記錄，數據庫量大的時候就設計分庫分表，也就是「分而治之」，把QPS和數據量分片限定在一個範圍內。
   當然還有很多其他相關的功能，如讀寫分離、路由策略、統計、管理、鑑權等等。這些是在業務邏輯之上的，不應該在業務代碼中把這部分堆進去，應該抽象它們出來作爲一個獨立的組件，這就是數據庫中間件。

2. Web框架中間件
   一般Web框架都支持中間件，Web框架中間件的本質是插件系統，是一系列的框架鉤子，在收到請求和返回響應這個過程裏面去做一些額外的事情。中間件種類很多，舉例一些：
   響應壓縮
   記錄日誌
   支持會話Session
   CSRF保護
   驗證/身份鑑別
   訪問控制
   資源使用檢查(如內存佔用)
   請求指標
   健康檢查
   靜態資源管理 …
   這些中間件將業務和非業務代碼功能進行解耦：
   框架裏面可能內置了一些常用的中間件，也可能只是內置中間件支持。你可以配置使用某個(些)，也能方便的自定義中間件
   Web視圖中不需要手寫中間件邏輯，按約定好的用法框架會在對應的生命週期中按照約定的順序去執行這些中間件邏輯

消息隊列(Message Queue)
消息隊列就是Message+Queue。其實消息可以說是一個數據傳輸單位，它包含了創建時間、通道/主題信息、輸入參數等全部數據;隊列(Queue)是一種FIFO(先進先出)的數據結構，編程語言一般都內置(內存中的)隊列實現，可以作爲進程間通訊(IPC)的方法。使用隊列最常見的場景就是生產者/消費者模式：生產者生產消息放到隊列中，消費者從隊列裏面獲取消息消費。
消息代理(Message Broker)
消息代理是一種架構模式，用於消息驗證、變換、路由。雖然不同的消息中間件架構和實現各不相同，但是大部分都實現了Broker：其實就是消息中間件服務器，它是中間件的核心。

Spring 中攔截器（Interceptor）與過濾器（Filter）的區別
攔截器 ：是在面向切面編程的就是在你的service或者一個方法，前調用一個方法，或者在方法後調用一個方法比如動態代理就是攔截器的簡單實現，在你調用方法前打印出字符串（或者做其它業務邏輯的操作），也可以在你調用方法後打印出字符串，甚至在你拋出異常的時候做業務邏輯的操作。
過濾器：是在javaweb中，你傳入的request、response提前過濾掉一些信息，或者提前設置一些參數，然後再傳入servlet或者struts的action進行業務邏輯，比如過濾掉非法url（不是login.do的地址請求，如果用戶沒有登陸都過濾掉），或者在傳入servlet或者 struts的action前統一設置字符集，或者去除掉一些非法字符.。
攔截器和過濾器比較
①攔截器是基於Java的反射機制的，而過濾器是基於函數回調。
②攔截器不依賴與servlet容器，依賴於web框架，在SpringMVC中就是依賴於SpringMVC框架。過濾器依賴與servlet容器。
③攔截器只能對action（也就是controller）請求起作用，而過濾器則可以對幾乎所有的請求起作用,並且可以對請求的資源進行起作用，但是缺點是一個過濾器實例只能在容器初始化時調用一次。
④攔截器可以訪問action上下文、值棧裏的對象，而過濾器不能訪問。
⑤在action的生命週期中，攔截器可以多次被調用，而過濾器只能在容器初始化時被調用一次。
⑥攔截器可以獲取IOC容器中的各個bean，而過濾器就不行，這點很重要，在攔截器裏注入一個service，可以調用業務邏輯
實現登錄狀態保持的兩種方法 cookie、session和token

實現登錄狀態保持的兩種方法：

第一種，cookie和session的配合使用
實現原理：當用戶請求頁面，一般需要先登錄，用戶第一次輸入用戶名和密碼之後，前臺發送post請求，後臺獲取用戶信息，通過查詢數據庫來驗證用戶信息是否正確，如果驗證通過，則會開闢一塊session空間來儲存用戶數據，並且同時生成一個cookie字符串，由後臺返回給前臺，前臺接收後，會把這個cookie字符串儲存到瀏覽器的cookie空間中，這個cookie就相當於一把鑰匙，可以打開後臺存儲對應用戶信息的鎖，當用戶下一次請求的時候，客戶端便會自動攜帶這個cookie去請求服務器，服務器識別後，就會讀取session中的用戶信息，這樣用戶就可以直接訪問，就不需要再輸入用戶名密碼來驗證身份了。
優缺點： 優點是：提升了用戶體驗，cookie和session的結合使用，比直接在客戶端保存用戶信息要相對安全；缺點是：當服務器向瀏覽器傳送cookie的時候，很容易被劫持，並不是絕對的安全，還有一點就是，在大型的項目中，服務器往往不只一臺，如果第一次請求，用戶信息被保存在了服務器1的session空間中，但是第二次請求被分流到了服務器2，這樣就獲取不到用戶信息了，依然要重新登錄，所以又引出了另一種方法：token來實現。
第二種，使用token安全令牌
實現原理：當用戶請求頁面，輸入用戶信息，服務端經過驗證後，會生成一個token安全令牌（隨機字符串），並返回給客戶端，當客戶端發送下一次請求的時候，直接攜帶這個token，服務端識別後，就可以直接訪問頁面，不需要再次登錄了
優點：token只是以字符串的形式存在，不要服務器再開闢空間，並且相對更安全，即使在傳輸的過程中被劫持，別人也並不能破解內容，並且減少了服務器壓力，減少頻繁的查詢數據庫。

JVM常見的調優參數包括：

-Xmx
指定java程序的最大堆內存, 使用java -Xmx5000M -version判斷當前系統能分配的最大堆內存
-Xms
指定最小堆內存, 通常設置成跟最大堆內存一樣，減少GC
-Xmn
　　設置年輕代大小。整個堆大小=年輕代大小 + 年老代大小。所以增大年輕代後，將會減小年老代大小。此值對系統性能影響較大，Sun官方推薦配置爲整個堆的3/8。
-Xss
　　指定線程的最大棧空間, 此參數決定了java函數調用的深度, 值越大調用深度越深, 若值太小則容易出棧溢出錯誤(StackOverflowError)
-XX:PermSize
　　指定方法區(永久區)的初始值,默認是物理內存的1/64， 在Java8永久區移除, 代之的是元數據區， 由-XX:MetaspaceSize指定
-XX:MaxPermSize
　　指定方法區的最大值, 默認是物理內存的1/4， 在java8中由-XX:MaxMetaspaceSize指定元數據區的大小
-XX:NewRatio=n
　　年老代與年輕代的比值，-XX:NewRatio=2, 表示年老代與年輕代的比值爲2:1
-XX:SurvivorRatio=n
Eden區與Survivor區的大小比值，-XX:SurvivorRatio=8表示Eden區與Survivor區的大小比值是8:1:1，因爲Survivor區有兩個(from, to)