Ⅰ 阿里怎麼談n+1
主要的還是靠自己，堅決的態度比較重要
下列是面試的方法流程
1 第一步，自我介紹:
個人答題方式:簡練的說出自己畢業於什麼大學，何時畢業;[本科],自學入行，平時研究java的方式，擅長哪些中間件，技術;自己工作中涉及的一些亮點項目，github自己的兩個項目【tcc,分庫分表】
控制在2分鍾左右，擅長的東西務必熟悉精通，接下來很有可能基於你的項目切入
2 第二步:面試問題
由我項目中涉及的自己開發的分庫分表組件切人
1 我的路由演算法: hash一致
1.1 項目怎麼實現的一致性演算法
1. hash一致性演算法怎麼實現，有什麼好
1.3 會有hash碰撞問題嗎，切到hashmap的hash碰撞相關問題
2 還有哪些路由演算法： 取模，時間片等
2.1 為什麼不用取模
2.2 取模優勢:[演算法更簡單，免去hash環的載入]，取模更容易平滑擴容
2.3 如何實現多個演算法 多個路由演算法引發的一些概念問題:面向抽象編程，依賴倒置
3設計模式:[選幾個自己熟悉的講 我講了下面三個]
模板方法
工廠
單例:單例的場景:[大對象一次載入，降低內存，IO，帶寬等]|[spring單例降低內存消耗] 懶漢單例安全的兩者實現[同步，靜態內部類]
4 由分庫分表引入到mysql
1 mysql 設計架構
2 innodb存儲引擎相關問題
3 b+樹，查詢復雜度，b+樹如何實現平衡，樹如何防止成為鏈表 ，b+樹的實現
4 索引如何建立:
5 索引如何調優:
5 最後:
面試官的建議建議基礎待加強，設計模式需要系統深入
詢能否現場面:回答可以
————————————————
版權聲明：本文為CSDN博主「歲月人」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_35529969/article/details/102556534
Ⅱ Android大廠面試經驗分享（OPPO，位元組，華為，阿里）
我是從小公司跳出來的，最終入職OPPO，說實話這段時間的經歷讓我深深地感受到，我們為跳槽做的一些臨時抱佛腳的提升跟那些大佬的沉澱比起來太渺小了。我們都知道找資料學習、刷面試題，但也許只能應付這一次的面試，後面還是會技術發愁，那些短時間背下來的東西遲早會忘掉， 大家還是做好長期提升自己的准備，好好沉澱的東西最後才是屬於自己的。
說說當時的面試過程，我是內推獲得的面試機會，很感謝當時幫我內推的兄弟，總共三輪面試，兩輪技術，一輪HR面，當天面試結束。
我10：10分到的公司，10：30開始面試，第一輪面試將近一個小時，聊的點我基本上都答得上來，自我感覺良好。然後面試官讓我等一下，他去叫他們老大來給我二面，我等了有二十幾分鍾吧，二面有一個多小時，這次問的比較深，有些地方答的有些嗑吧，總體來說我自己是滿意的。HR面約到下午了，整個流程下來每輪面試官都讓人感覺很不錯，我自己做的准備也讓我面試感覺下來很爽。
我把面試遇到過的以及自己學慣用到過相關內容都整理到一起了，方便自己進行復盤和後續的查漏補缺：
一、 Java基礎
1.1 靜態內部類和非靜態內部類的比較
1.2 多態的理解與應用
1.3 java方法的多態性理解
1.4 java中介面和繼承的區別
1.5 線程池的好處，詳解，單例（絕對好記）
1.6 線程池的優點及其原理
1.7 線程池的優點（重點）
1.8 為什麼不推薦通過Executors直接創建線程池
1.9 不怕難之BlockingQueue及其實現
1.10 深入理解ReentrantLock與Condition
1.11 Java多線程：線程間通信之Lock
1.12 Synchronized 關鍵字原理
1.13 ReentrantLock原理
1.14 HashMap中的Hash沖突解決和擴容機制
1.14 Java並發
1.15 Java虛擬機
1.16 JVM常見面試題
1.17 JVM內存結構
1.18 類載入機制/雙親委託
二、 Android基礎
2.1 Activity知識點(必問)
2.2 Fragment知識點
2.3 Service知識點
2.4 Intent知識點
2.5 數據存儲
三、UI控制項篇
3.1 屏幕適配
3.2 主要控制項優化
3.3 事件分發與嵌套滾動
3.4 動態化頁面構建方案
四、網路通信篇
4.1 網路協議
五、架構設計篇
5.1 MVP架構設計
5.2 組件化架構
六、性能優化篇
6.1 啟動優化
6.2 內存優化
6.3 繪制優化
6.4 安裝包優化
七、源碼流程篇
7.1 開源庫源碼分析
7.2 Glide源碼分析
7.3 day 20 面試題：Glide面試題
7.4 聊一聊關於Glide在面試中的那些事
7.5 面試官：簡歷上如果寫Glide，請注意以下幾點…
7.6 Glide OOM問題解決方法匯總
7.7 LeakCanary源碼分析
7.8 OkHttp源碼分析
7.9 okhttp連接池復用機制
7.10 okhttp 流程和優化的實現
7.11 一篇讓你受用的okhttp分析
7.12 OkHttp面試之–OkHttp的整個非同步請求流程
7.13 OkHttp面試之–HttpEngine中的sendRequest方法詳解
7.14 OkHttp解析大總結
7.15 Okhttp任務隊列工作原理
7.16 Android高頻面試專題 - 架構篇（二）okhttp面試必知必會
7.17 Android 網路優化，使用 HTTPDNS 優化 DNS，從原理到 OkHttp 集成
7.18 Retrofit源碼分析
7.19 RxJava源碼分析
7.20 RxJava原理與源碼分析
7.21 RxJava如何進行線程切換的？
7.22 Rxjava內存泄漏防止方案——RxLifecycle，AutoDispose，RxLife框架
7.23 Tinker源碼分析
7.24 ARouter源碼分析
7.25 Android框架層源碼解析
7.26 演算法設計
八、新技術篇
8.1 實戰問題篇
九、面試篇
9.1 開源文檔
9.2 面試文獻
以上就是我的學習和面試積累，有自己面試經歷過的，也有整理的一些大廠面試題，篇幅有限，具體內容就不展示了，我已經整理成文檔了。
還是開頭說的，僅靠面試期間臨時抱佛腳和刷題對自身發展不是長久之計，做好長期提升的規劃，好好沉澱每一次的學習和面試經歷，把這些最終都轉化成屬於自己的東西才是實質上對自己最有用的。
Ⅲ 阿裡面試題：50枚硬幣拿取問題
題目面試：桌面上有50枚硬幣，一次可以拿2,4,6枚，另一位同學和你競爭，你拿一次，他拿一次，怎麼保證最後一枚硬幣是你拿到。
解題思路：這種問題可以從後往前推，如果要保證最後一枚硬幣你拿到，那麼你倒數第二次拿硬幣後應該剩下8枚，此時另外一名同學不管是拿2枚，4枚，6枚，那麼你肯定能拿到最後一枚。50-8=42 剩下42枚，怎麼拿取？可以觀察2 4 6 這幾個數字的特點，4+4=8 2+6=8 6+2=8，不管另一位同學拿幾枚，你都可以和他湊成8枚，42-5X8=2，最後剩下兩枚，你先拿。
答案：你先拿2枚，另一個同學如果拿2枚，你拿6枚，另一個同學如果拿4枚，你也拿4枚，另一個同學如果拿6枚，你拿2枚，這樣重復5個回合，最後剩下8枚，不管他怎麼拿，你都能拿到最後一枚。
Ⅳ 史上最全 40 道 Dubbo 面試題及答案，看完碾壓面試官！
Dubbo是阿里巴巴開源的高性能RPC分布式服務框架，現已成為Apache基金會孵化項目。使用Dubbo可以將核心業務抽取為服務，形成穩定的服務中心，提高業務復用性和靈活性，應對市場多變需求。Dubbo內部使用了Netty和Zookeeper，確保高性能和高可用性。
選擇Dubbo的原因在於它是阿里開源項目，廣泛應用於國內互聯網公司，經過線上考驗。使用Dubbo可以提高業務復用和擴展性，實現分布式架構，以應對更大並發流量。以下是Dubbo的核心特點和部分面試問題答案：
1. Dubbo是什麼？
Dubbo是基於Java的高性能RPC分布式服務框架。
2. 為什麼要用Dubbo？
Dubbo是阿里開源項目，具有高可用性和性能，適用於分布式架構，能夠提高業務復用性和擴展性。
3. Dubbo和Spring Cloud的區別？
Dubbo和Spring Cloud在通信方式、組成部分和特定功能上有所不同。
4. Dubbo支持哪些協議？
Dubbo支持多種協議，推薦使用RPC通信。
5. Dubbo需要Web容器嗎？
不需要，使用Web容器只會增加復雜性並浪費資源。
6. Dubbo內置了哪些服務容器？
Dubbo使用簡單的Spring容器來暴露服務。
7. Dubbo有哪些節點角色？
節點角色包括提供者、消費者、注冊中心、監控中心和容器。
8. 畫出服務注冊與發現流程圖。
服務注冊與發現流程圖展示了Dubbo服務注冊中心的運作。
9. Dubbo使用什麼注冊中心？
推薦使用Zookeeper作為注冊中心，還有其他選擇。
10. Dubbo的配置方式有哪些？
Dubbo支持Spring配置和Java API配置。
11. Dubbo的核心配置有哪些？
核心配置包括服務、引用、協議、應用、模塊、注冊中心、監控中心、提供者和消費者等。
12. 在Provider上可以配置哪些Consumer端屬性？
可以配置超時、重試次數、負載均衡演算法和並發限制。
13. Dubbo啟動時依賴服務不可用會怎樣？
Dubbo會在啟動時檢查依賴服務，不可用時拋出異常。
14. Dubbo推薦的序列化框架有哪些？
推薦Hessian序列化，還有Duddo、FastJson和Java序列化。
15. Dubbo的通信框架？
默認使用Netty框架，集成有Mina、Grizzly等。
16. Dubbo的集群容錯方案有哪些？
包括失敗自動切換、快速失敗、失敗安全、失敗自動恢復和並行調用等。
17. Dubbo的負載均衡策略有哪些？
包括隨機、輪詢、最少活躍調用數和一致性Hash。
18. 多個服務注冊時如何測試特定服務？
可以配置環境點對點直連，繞過注冊中心。
19. Dubbo支持多協議嗎？
支持配置多協議，允許在同一服務上使用多種協議。
20. 多種服務實現同一介面時如何處理？
使用group屬性分組，服務提供方和消費方都指定同一group。
21. 如何兼容舊版本？
使用版本號過渡，多個不同版本服務注冊，版本號不同不引用。
22. Dubbo支持緩存嗎？
提供聲明式緩存加速訪問。
23. Dubbo服務調用是阻塞的嗎？
默認阻塞，支持非同步調用。
24. Dubbo支持分布式事務嗎？
暫不支持，可能通過JTA/XA規范實現。
25. Dubbo telnet命令的作用？
用於服務治理，具體使用請參考文章。
26. Dubbo支持服務降級嗎？
2.2.0以上版本支持。
27. 如何優雅停機？
通過JDK的ShutdownHook完成，強制關閉不會執行。
28. 服務失效踢出原理？
基於Zookeeper的臨時節點原理。
29. 解決服務調用鏈過長？
使用Pinpoint和Apache Skywalking實現分布式服務追蹤。
30. 服務讀寫容錯策略？
讀操作建議使用失敗自動切換，寫操作快速失敗。
31. Dubbo必須依賴的包？
必須依賴JDK，其他為可選。
32. 管理控制台功能？
包含路由規則、動態配置、服務降級、訪問控制、權重調整、負載均衡等功能。
33. Dubbo服務暴露過程？
Spring實例化bean後，在容器刷新最後一步發布事件，通知ServiceBean回調事件方法，實現服務發布。
34. Dubbo的維護狀態？
2014年後停止維護，17年開始重新維護並進入Apache項目。
35. Dubbo和Dubbox的區別？
Dubbox是當當網基於Dubbo的擴展項目，增加了服務調用的RESTful特性等。
36. 其他分布式框架？
還有Spring Cloud、Facebook的Thrift、Twitter的Finagle等。
37. Dubbo能集成Spring Boot嗎？
可以集成，項目地址為Apache Dubbo的GitHub倉庫。
38. 遇到的問題？
在大數據量下性能不佳，建議使用RMI或HTTP協議。
39. 閱讀Dubbo源碼？
了解Dubbo原理需要閱讀源碼，網上有教程可供參考。
40. Dubbo和Spring Cloud的評價？
Spring Cloud組件頻繁更新，配置復雜，與Dubbo相比，個人更傾向於使用Dubbo。
以上內容涵蓋了Dubbo的常見面試問題和使用細節，希望對大家有所幫助。
Ⅳ 【騰訊阿里最全面試題】介紹下Synchronized、Volatile、CAS、AQS，以及各自的使用場景
面試中出現概念最高的技術-原來就是這個鎖
後台開發中必備技能—鎖；原子操作 CAS
線程鎖、進程鎖、分布式鎖以及資料庫鎖
鎖概述
談到並發，不得不談ReentrantLock；而談ReentrantLock，不得不談AbstractQueuedSynchronizer（AQS）！AQS定義了一套多線程訪問共享資源的同步器框架，許多同步類實現都依賴於它，如常用的ReentrantLock/Semaphore/CountDownLatch等。
lock實現過程中的幾個關鍵詞：計數值、雙向鏈表、CAS+自旋
lock的存儲結構：一個int類型狀態值（用於鎖的狀態變更），一個雙向鏈表（用於存儲等待中的線程）
lock獲取鎖的過程：本質上是通過CAS來獲取狀態值修改，如果當場沒獲取到，會將該線程放在線程等待鏈表中。
lock釋放鎖的過程：修改狀態值，調整等待鏈表。
可以看到在整個實現過程中，lock大量使用CAS+自旋。因此根據CAS特性，lock建議使用在低鎖沖突的情況下。目前java1.6以後，官方對synchronized做了大量的鎖優化（偏向鎖、自旋、輕量級鎖）。因此在非必要的情況下，建議使用synchronized做同步操作。
Abstract Queued Synchronizer (AQS) 維護了一個state（代表了共享資源）和一個FIFO線程等待隊列（多線程競爭資源被阻塞時會將線程放入此隊列）。 由於state是由volatile修飾的所以該變數的改動都是立等可見的。
AQS 定義了兩種資源共享的方式 Exclusive（獨占，一時間只有一個線程能訪問該資源）、Share (共享，一時間可以有多個線程訪問資源).
獨占模式就像共享單車一時間只有一個人可以騎這個共享單車，共享模式就像公交車可以上去很多人，但是人一旦上滿了就不能在上人了，必須要等車上的人下來後才能繼續上人。
AQS的兩種功能從使用層面來說，AQS的功能分為兩種：獨占和共享。
ReentrantLock的簡單實用如何在實際應用中使用ReentrantLock呢？我們通過一個簡單的demo來演示一下。這段代碼主要做一件事，就是通過一個靜態的incr()方法對共享變數count做連續遞增，在沒有加同步鎖的情況下多線程訪問這個方法一定會存在線程安全問題。所以用到了ReentrantLock來實現同步鎖，並且在finally語句塊中釋放鎖。 那麼我來引出一個問題，大家思考一下多個線程通過lock競爭鎖時，當競爭失敗的鎖是如何實現等待以及被喚醒的呢?
什麼是AQS？AQS，全稱為AbstractQueuedSynchronizer，它提供了一個FIFO隊列，可以看成是一個用來實現同步鎖以及其他涉及到同步功能的核心組件，常見的有:ReentrantLock、CountDownLatch等。 AQS是一個抽象類，主要是通過繼承的方式來使用，它本身沒有實現任何的同步介面，僅僅是定義了同步狀態的獲取以及釋放的方法來提供自定義的同步組件。 可以這么說，只要搞懂了AQS，那麼J.U.C中絕大部分的api都能輕松掌握。
AQS的內部實現AQS的實現依賴內部的同步隊列,也就是FIFO的雙向隊列，如果當前線程競爭鎖失敗，那麼AQS會把當前線程以及等待狀態信息構造成一個Node加入到同步隊列中，同時再阻塞該線程。當獲取鎖的線程釋放鎖以後，會從隊列中喚醒一個阻塞的節點(線程)。
AQS隊列內部維護的是一個FIFO的雙向鏈表，這種結構的特點是每個數據結構都有兩個指針，分別指向直接的後繼節點和直接前驅節點。所以雙向鏈表可以從任意一個節點開始很方便的訪問前驅和後繼。每個Node其實是由線程封裝，當線程爭搶鎖失敗後會封裝成Node加入到ASQ隊列中去。
Node類的組成如下
ReentrantLock的時序圖調用ReentrantLock中的lock()方法，源碼的調用過程我使用了時序圖來展現。從圖上可以看出來，當鎖獲取失敗時，會調用addWaiter()方法將當前線程封裝成Node節點加入到AQS隊列，基於這個思路，我們來分析AQS的源碼實現。
ReentrantLock.lock()這個是獲取鎖的入口，調用sync這個類裡面的方法，sync是什麼呢？sync是一個靜態內部類，它繼承了AQS這個抽象類，前面說過AQS是一個同步工具，主要用來實現同步控制。我們在利用這個工具的時候，會繼承它來實現同步控制功能。 通過進一步分析，發現Sync這個類有兩個具體的實現，分別是NofairSync(非公平鎖),FailSync(公平鎖).
acquire這個方法的主要邏輯是
Synchronized源碼分析NonfairSync.tryAcquire這個方法的作用是嘗試獲取鎖，如果成功返回true，不成功返回false 它是重寫AQS類中的tryAcquire方法，並且大家仔細看一下AQS中tryAcquire方法的定義，並沒有實現，而是拋出異常。按照一般的思維模式，既然是一個不實現的模版方法，那應該定義成abstract，讓子類來實現呀？大家想想為什麼
nonfairTryAcquire tryAcquire(1)在NonfairSync中的實現代碼如下
文章福利 Linux後端開發網路底層原理知識學習提升 點擊 學習資料 獲取，完善技術棧，內容知識點包括Linux，Nginx，ZeroMQ，MySQL，Redis，線程池，MongoDB，ZK，Linux內核，CDN，P2P，epoll，Docker，TCP/IP，協程，DPDK等等。
addWaiter 當tryAcquire方法獲取鎖失敗以後，則會先調用addWaiter將當前線程封裝成Node，然後添加到AQS隊列
enq enq就是通過自旋操作把當前節點加入到隊列中
acquireQueued 將添加到隊列中的Node作為參數傳入acquireQueued方法，這裡面會做搶占鎖的操作
shouldParkAfterFailedAcquire 從上面的分析可以看出，只有隊列的第二個節點可以有機會爭用鎖，如果成功獲取鎖，則此節點晉升為頭節點。對於第三個及以後的節點，if (p == head)條件不成立，首先進行shouldParkAfterFailedAcquire(p, node)操作 shouldParkAfterFailedAcquire方法是判斷一個爭用鎖的線程是否應該被阻塞。它首先判斷一個節點的前置節點的狀態是否為Node.SIGNAL，如果是，是說明此節點已經將狀態設置-如果鎖釋放，則應當通知它，所以它可以安全的阻塞了，返回true。
parkAndCheckInterrupt 如果shouldParkAfterFailedAcquire返回了true，則會執行：parkAndCheckInterrupt()方法，它是通過LockSupport.park(this)將當前線程掛起到WATING狀態，它需要等待一個中斷、unpark方法來喚醒它，通過這樣一種FIFO的機制的等待，來實現了Lock的操作。
LockSupport LockSupport類是Java6引入的一個類，提供了基本的線程同步原語。LockSupport實際上是調用了Unsafe類里的函數，歸結到Unsafe里，只有兩個函數： public native void unpark(Thread jthread); public native void park(boolean isAbsolute, long time); unpark函數為線程提供「許可(permit)」，線程調用park函數則等待「許可」。這個有點像信號量，但是這個「許可」是不能疊加的，「許可」是一次性的。 permit相當於0/1的開關，默認是0，調用一次unpark就加1變成了1.調用一次park會消費permit，又會變成0。 如果再調用一次park會阻塞，因為permit已經是0了。直到permit變成1.這時調用unpark會把permit設置為1.每個線程都有一個相關的permit，permit最多隻有一個，重復調用unpark不會累積
鎖的釋放ReentrantLock.unlock 加鎖的過程分析完以後，再來分析一下釋放鎖的過程，調用release方法，這個方法裡面做兩件事，1，釋放鎖 ；2，喚醒park的線程
tryRelease 這個動作可以認為就是一個設置鎖狀態的操作，而且是將狀態減掉傳入的參數值（參數是1），如果結果狀態為0，就將排它鎖的Owner設置為null，以使得其它的線程有機會進行執行。 在排它鎖中，加鎖的時候狀態會增加1（當然可以自己修改這個值），在解鎖的時候減掉1，同一個鎖，在可以重入後，可能會被疊加為2、3、4這些值，只有unlock()的次數與lock()的次數對應才會將Owner線程設置為空，而且也只有這種情況下才會返回true。
unparkSuccessor 在方法unparkSuccessor(Node)中，就意味著真正要釋放鎖了，它傳入的是head節點（head節點是佔用鎖的節點），當前線程被釋放之後，需要喚醒下一個節點的線程