1.3 計算機網(wǎng)絡(luò)
- 基礎(chǔ)
Q：五層協(xié)議的體系結(jié)構(gòu)分別是什么域庇？每一層都有哪些協(xié)議？
- 技術(shù)點：網(wǎng)絡(luò)模型驶鹉、協(xié)議
- 思路：分條解釋每層名字以及協(xié)議
- 參考回答：
- 物理層
- 數(shù)據(jù)鏈路層：邏輯鏈路控制LLC、媒體接入控制MAC
- 網(wǎng)絡(luò)層：IP協(xié)議、地址解析協(xié)議ARP航揉、逆地址解析協(xié)議RARP、因特網(wǎng)控制報文協(xié)議ICMP
- 傳輸層：傳輸控制協(xié)議TCP金刁、用戶數(shù)據(jù)報協(xié)議UDP
- 應(yīng)用層：文件傳輸協(xié)議FTP帅涂、遠程登錄協(xié)議TELNET、超文本傳輸協(xié)議HTTP尤蛮、域名系統(tǒng)DNS媳友、簡單郵件協(xié)議SMTP、簡單網(wǎng)絡(luò)管理協(xié)議SNMP
Q：為何有MAC地址還要IP地址产捞？
- 技術(shù)點：MAC地址醇锚、IP地址
- 參考回答：
- 每臺主機在出廠時都有一個唯一的MAC地址，但是IP地址的分配是根據(jù)網(wǎng)絡(luò)的拓樸結(jié)構(gòu)坯临，得以保證路由選擇方案建立在網(wǎng)絡(luò)所處的拓撲位置基礎(chǔ)而不是設(shè)備制造商的基礎(chǔ)上
- 使用IP地址更方便數(shù)據(jù)傳輸焊唬。數(shù)據(jù)包在這些節(jié)點之間的移動都是由ARP協(xié)議負責將IP地址映射到MAC地址上來完成的。
- TCP
Q：TCP和UDP的區(qū)別尿扯？
- 技術(shù)點：傳輸層協(xié)議對比
- 參考回答：
- TCP傳輸控制協(xié)議：面向連接求晶；使用全雙工的可靠信道；提供可靠的服務(wù)衷笋，即無差錯芳杏、不丟失、不重復且按序到達辟宗；擁塞控制爵赵、流量控制、超時重發(fā)泊脐、丟棄重復數(shù)據(jù)等等可靠性檢測手段空幻；面向字節(jié)流；每條TCP連接只能是點到點的容客；用于傳輸可靠性要求高的數(shù)據(jù)
- UDP用戶數(shù)據(jù)報協(xié)議：無連接秕铛；使用不可靠信道；盡最大努力交付缩挑，即不保證可靠交付但两；無擁塞控制等；面向報文供置；支持一對一谨湘、一對多、多對一和多對多的交互通信；用于傳輸可靠性要求不高的數(shù)據(jù)
Q：擁塞控制和流量控制都是什么紧阔，兩者的區(qū)別坊罢？
- 技術(shù)點：擁塞控制、流量控制
- 參考回答：
- 擁塞控制：對網(wǎng)絡(luò)中的路由和鏈路傳輸進行速度限制擅耽，避免網(wǎng)絡(luò)過載活孩；包含四個過程：慢啟動、擁塞避免秫筏、快重傳和快恢復
- 流量控制 ：對點和點/發(fā)送方和接收方之間進行速度匹配诱鞠，由于接收方的應(yīng)用程序讀取速度不一定很迅速挎挖，加上緩存有限这敬，因此需要避免發(fā)送速度過快；相關(guān)技術(shù)：TCP滑動窗口蕉朵、回退N針協(xié)議
Q：談?wù)凾CP為什么要三次握手崔涂？為什么要四次揮手？
- 技術(shù)點：TCP可靠保證
- 參考回答：
（1）建立TCP連接：TCP的三次握手
- 客戶端向服務(wù)端發(fā)送一個表示建立連接的報文段SYN報文段始衅；一旦包含SYN報文段的IP數(shù)據(jù)報到達服務(wù)器主機冷蚂，服務(wù)器從IP數(shù)據(jù)報中提取出TCP、SYN報文段汛闸，為該TCP連接分配需要的緩存和變量蝙茶，并向客戶端發(fā)送表示允許連接的報文段ACK；在收到ACK報文段之后诸老，客戶端也要給該連接分配緩存和變量隆夯，客戶端向服務(wù)器再發(fā)送一個報文段ACK，表示對允許連接的報文段進行了確認别伏。自此完成一次TCP連接蹄衷。
- 第三次握手可以避免由于客戶端延遲的請求連接的請求，使得服務(wù)端無故再次建立連接厘肮。
（2）斷開TCP連接：TCP的四次揮手
- 由于TCP連接是全雙工的愧口，因此每個方向都必須單獨關(guān)閉±嗝客戶端在數(shù)據(jù)發(fā)送完畢后發(fā)送一個結(jié)束數(shù)據(jù)段FIN耍属，且服務(wù)端也返回確認數(shù)據(jù)段ACK，此時結(jié)束了客戶端到服務(wù)端的連接巩检；然后客戶端接收到服務(wù)端發(fā)送的FIN碱工，且服務(wù)端也收到了ACK之后，自此雙方的數(shù)據(jù)通信完全結(jié)束嘶朱。簡單說來是 “先關(guān)讀配并，后關(guān)寫”，一共需要四個階段：服務(wù)器讀通道關(guān)閉->客戶機寫通道關(guān)閉->客戶機讀通道關(guān)閉->服務(wù)器寫通道關(guān)閉。
- 引申：談?wù)効蛻舳说竭_的TIME_WAIT狀態(tài)時間是MaximumSegmentLifetime的兩倍提揍，而不是直接進入CLOSED狀態(tài)的原因啤月。（保證TCP協(xié)議的全雙工連接能夠可靠關(guān)閉、保證本次連接的重復數(shù)據(jù)段從網(wǎng)絡(luò)中消失）
Q：播放視頻用TCP還是UDP劳跃？為什么谎仲？
- 技術(shù)點：傳輸層協(xié)議適用場景
- 參考回答：播放視頻適合用UDP。UDP適用于對網(wǎng)絡(luò)通訊質(zhì)量要求不高刨仑、要求網(wǎng)絡(luò)通訊速度能盡量快的實時性應(yīng)用郑诺；而TCP適用于對網(wǎng)絡(luò)通訊質(zhì)量有要求的可靠性應(yīng)用。而且視頻區(qū)分關(guān)鍵幀和普通幀杉武，雖然UDP會丟幀但如果只是丟普通幀損失并不大辙诞，取而代之的是高速率和實時性。
- 引申：TCP轻抱、UDP適用的場景
- HTTP
Q：了解哪些響應(yīng)狀態(tài)碼飞涂？
- 技術(shù)點：響應(yīng)狀態(tài)碼
- 思路：
- 參考回答：狀態(tài)碼由三位數(shù)字組成，第一位數(shù)字表示響應(yīng)的類型祈搜，常用的狀態(tài)碼有五大類：
- 1xx：表示服務(wù)器已接收了客戶端請求较店，客戶端可繼續(xù)發(fā)送請求
- 2xx：表示服務(wù)器已成功接收到請求并進行處理
- 200 OK：表示客戶端請求成功
- 3xx：表示服務(wù)器要求客戶端重定向
- 4xx：表示客戶端的請求有非法內(nèi)容
- 400 Bad Request：表示客戶端請求有語法錯誤，不能被服務(wù)器所理解
- 401 Unauthonzed：表示請求未經(jīng)授權(quán)容燕，該狀態(tài)代碼必須與 WWW-Authenticate 報頭域一起使用
- 403 Forbidden：表示服務(wù)器收到請求梁呈，但是拒絕提供服務(wù)，通常會在響應(yīng)正文中給出不提供服務(wù)的原因
- 404 Not Found：請求的資源不存在蘸秘，例如官卡，輸入了錯誤的URL
- 5xx：表示服務(wù)器未能正常處理客戶端的請求而出現(xiàn)意外錯誤
- 500 Internal Server Error：表示服務(wù)器發(fā)生不可預(yù)期的錯誤，導致無法完成客戶端的請求
- 503 Service Unavailable：表示服務(wù)器當前不能夠處理客戶端的請求秘血，在一段時間之后味抖，服務(wù)器可能會恢復正常
Q：get和post的區(qū)別？
- 技術(shù)點：HTTP請求方法
- 參考回答：
- GET：當客戶端要從服務(wù)器中讀取某個資源時使用GET灰粮；一般用于獲取/查詢資源信息仔涩；GET參數(shù)通過URL傳遞，傳遞的參數(shù)是有長度限制粘舟，不能用來傳遞敏感信息
- POST：當客戶端給服務(wù)器提供信息較多時可以使用POST熔脂；POST會附帶用戶數(shù)據(jù)，一般用于更新資源信息柑肴；POST將請求參數(shù)封裝在HTTP 請求數(shù)據(jù)中霞揉，可以傳輸大量數(shù)據(jù)，傳參方式比GET更安全
Q：HTTP1.0晰骑、HTTP1.1适秩、HTTP2.0的區(qū)別？
- 技術(shù)點：HTTP協(xié)議發(fā)展
- 參考回答：
- （1）HTTP1.0和HTTP1.1的區(qū)別：
- HTTP1.0默認使用短連接，HTTP1.1開始默認使用長連接
- HTTP1.1增加更多的請求頭和響應(yīng)頭來改進和擴充HTTP1.0的功能秽荞，比如身份認證骤公、狀態(tài)管理和Cache緩存等
- （2）HTTP2.0和HTTP1.X相比的新特性：
- 新的二進制格式：HTTP2.0的協(xié)議解析決定采用二進制格式，實現(xiàn)方便且健壯扬跋，不同于HTTP1.x的解析是基于文本
- 多路復用：連接共享阶捆，即每一個request都是是用作連接共享機制的
- 服務(wù)端推送：服務(wù)器主動向客戶端推送消息
- 引申：長連接和短連接的優(yōu)缺點和適用場景，HTTP 長連接和短連接
Q：HTTP和TCP的區(qū)別
- 技術(shù)點：HTTP钦听、TCP
- 參考回答：
- TCP是傳輸層協(xié)議洒试，定義數(shù)據(jù)傳輸和連接方式的規(guī)范。通過三次握手建立連接朴上、四次揮手釋放連接垒棋。
- HTTP是應(yīng)用層協(xié)議，定義的是傳輸數(shù)據(jù)的內(nèi)容的規(guī)范余指。HTTP的連接使用"請求-響應(yīng)"方式捕犬□伟樱基于TCP協(xié)議傳輸酵镜，默認端口號是80。
Q：HTTP和HTTPS的區(qū)別
- 技術(shù)點：HTTP柴钻、HTTPS
- HTTP（超文本傳輸協(xié)議）：運行在TCP之上淮韭；傳輸?shù)膬?nèi)容是明文；端口是80
- HTTPS（安全為目標的HTTP）：運行在SSL/TLS之上贴届，SSL/TLS運行在TCP之上靠粪；傳輸?shù)膬?nèi)容經(jīng)過加密；端口是443
Q：HTTP和Socket的區(qū)別-
- 技術(shù)點：HTTP毫蚓、Socket
- 參考回答：
- HTTP是應(yīng)用層協(xié)議占键；基于TCP協(xié)議；使用“請求—響應(yīng)”方式建立連接元潘，在請求時需要先建立連接且客戶端要先發(fā)出請求畔乙，可見服務(wù)器需要等到客戶端發(fā)送一次請求后才能將數(shù)據(jù)傳回給客戶端
- Socket（套接字）是對TCP/IP協(xié)議的封裝，是接口而不是協(xié)議翩概；創(chuàng)建Socket連接時可以指定傳輸層協(xié)議TCP或UDP牲距；Socket建立連接過程三步驟：服務(wù)器監(jiān)聽->客戶端請求->連接確認，可見服務(wù)器可以直接將數(shù)據(jù)傳送給客戶端（HTTP2.0也增加了服務(wù)端推送的功能）
Q：在地址欄打入URL會發(fā)生什么钥庇？
- 技術(shù)點：理解網(wǎng)絡(luò)模型
- 參考回答：在瀏覽器地址欄鍵入URL牍鞠，按下回車之后會經(jīng)歷以下流程：
- 瀏覽器向DNS服務(wù)器請求解析該URL中的域名所對應(yīng)的IP地址
- 解析出IP地址后，根據(jù)該IP地址和默認端口80评姨，和服務(wù)器建立TCP連接
- 瀏覽器發(fā)出讀取文件的HTTP請求难述，該請求報文作為TCP三次握手的第三個報文的數(shù)據(jù)發(fā)送給服務(wù)器
- 服務(wù)器對瀏覽器請求作出響應(yīng)，并把對應(yīng)的html文本發(fā)送給瀏覽器
- 釋放TCP連接，若connection模式為close胁后，則服務(wù)器主動關(guān)閉TCP連接硫眯，客戶端被動關(guān)閉連接，釋放TCP連接择同；若connection模式為keepalive两入，則該連接會保持一段時間，在該時間內(nèi)可以繼續(xù)接收請求
- 客戶端將服務(wù)器響應(yīng)的html文本解析并顯示
1.4 JVM
Q：JVM內(nèi)存是如何劃分的敲才？
- 技術(shù)點：JVM內(nèi)存管理
- 思路：分條解釋每部分內(nèi)存的作用裹纳，詳見要點提煉| 理解JVM之內(nèi)存管理
- 參考回答：JVM會用一段空間來存儲執(zhí)行程序期間需要用到的數(shù)據(jù)和相關(guān)信息，這段空間就是運行時數(shù)據(jù)區(qū)（Runtime Data Area）紧武，也就是常說的JVM內(nèi)存剃氧。JVM會將它所管理的內(nèi)存劃分為線程私有數(shù)據(jù)區(qū)和線程共享數(shù)據(jù)區(qū)兩大類：
- 線程私有數(shù)據(jù)區(qū)包含：
- 程序計數(shù)器：是當前線程所執(zhí)行的字節(jié)碼的行號指示器
- 虛擬機棧：是Java方法執(zhí)行的內(nèi)存模型
- 本地方法棧：是虛擬機使用到的Native方法服務(wù)
- 線程共享數(shù)據(jù)區(qū)包含：
- Java堆：用于存放幾乎所有的對象實例和數(shù)組；是垃圾收集器管理的主要區(qū)域阻星，也被稱做“GC堆”朋鞍；是Java虛擬機所管理的內(nèi)存中最大的一塊
- 方法區(qū)：用于存儲已被虛擬機加載的類信息、常量妥箕、靜態(tài)變量滥酥、即時編譯器編譯后的代碼等數(shù)據(jù)；Class文件中除了有類的版本畦幢、字段坎吻、方法、接口等描述信息外宇葱，還有一項信息是常量池（Constant Pool Table）瘦真，用于存放編譯期生成的各種字面量和符號引用，這部分內(nèi)容將在類加載后進入方法區(qū)的運行時常量池中存放
- 引申：談?wù)凧VM的堆和棧差別
Q：談?wù)劺厥諜C制黍瞧？為什么引用計數(shù)器判定對象是否回收不可行诸尽？知道哪些垃圾回收算法？
- 技術(shù)點：垃圾回收機制
- 思路：從如何判定對象可回收印颤、如果回收具體算法這兩方面展開談垃圾回收機制您机，詳見要點提煉| 理解JVM之GC
- 參考回答：
- （1）判定對象可回收有兩種方法：
- 引用計數(shù)算法：給對象中添加一個引用計數(shù)器，每當有一個地方引用它時膀哲，計數(shù)器值就加1往产；當引用失效時，計數(shù)器值就減1某宪；任何時刻計數(shù)器為0的對象就是不可能再被使用的仿村。然而在主流的Java虛擬機里未選用引用計數(shù)算法來管理內(nèi)存，主要原因是它難以解決對象之間相互循環(huán)引用的問題兴喂，所以出現(xiàn)了另一種對象存活判定算法蔼囊。
- 可達性分析法：通過一系列被稱為『GC Roots』的對象作為起始點焚志，從這些節(jié)點開始向下搜索，搜索所走過的路徑稱為引用鏈畏鼓，當一個對象到GC Roots沒有任何引用鏈相連時酱酬，則證明此對象是不可用的。其中可作為GC Roots的對象：虛擬機棧中引用的對象云矫，主要是指棧幀中的本地變量膳沽、本地方法棧中Native方法引用的對象、方法區(qū)中類靜態(tài)屬性引用的對象让禀、方法區(qū)中常量引用的對象
- （2）回收算法有以下四種：
- 分代收集算法：是當前商業(yè)虛擬機都采用的一種算法挑社，根據(jù)對象存活周期的不同，將Java堆劃分為新生代和老年代巡揍，并根據(jù)各個年代的特點采用最適當?shù)氖占惴ā?
- 新生代：大批對象死去痛阻，只有少量存活。使用『復制算法』腮敌，只需復制少量存活對象即可阱当。
- 復制算法：把可用內(nèi)存按容量劃分為大小相等的兩塊，每次只使用其中的一塊糜工。當這一塊的內(nèi)存用盡后弊添，把還存活著的對象『復制』到另外一塊上面，再將這一塊內(nèi)存空間一次清理掉啤斗。
- 老年代：對象存活率高表箭。使用『標記—清理算法』或者『標記—整理算法』，只需標記較少的回收對象即可钮莲。
- 標記-清除算法：首先『標記』出所有需要回收的對象，然后統(tǒng)一『清除』所有被標記的對象彼水。
- 標記-整理算法：首先『標記』出所有需要回收的對象崔拥，然后進行『整理』，使得存活的對象都向一端移動凤覆，最后直接清理掉端邊界以外的內(nèi)存链瓦。
- 引申：談?wù)劽糠N回收算法的優(yōu)缺點
Q：Java中引用有幾種類型？在Android中常用于什么情景盯桦？
- 技術(shù)點：Java引用類型
- 思路：分條解釋每種類型的特點和適用場景慈俯，詳見要點提煉| 理解JVM之GC
- 參考回答：引用的四種類型
- 強引用（StrongReference）：具有強引用的對象不會被GC；即便內(nèi)存空間不足拥峦，JVM寧愿拋出OutOfMemoryError使程序異常終止贴膘，也不會隨意回收具有強引用的對象。
- 軟引用（SoftReference）：只具有軟引用的對象略号，會在內(nèi)存空間不足的時候被GC刑峡；軟引用常用來實現(xiàn)內(nèi)存敏感的高速緩存洋闽。
- 弱引用（WeakReference）：只被弱引用關(guān)聯(lián)的對象，無論當前內(nèi)存是否足夠都會被GC突梦；強度比軟引用更弱诫舅，常用于描述非必需對象；常用于解決內(nèi)存泄漏的問題
- 虛引用（PhantomReference）：僅持有虛引用的對象宫患，在任何時候都可能被GC刊懈；常用于跟蹤對象被GC回收的活動；必須和引用隊列 （ReferenceQueue）聯(lián)合使用娃闲，當垃圾回收器準備回收一個對象時俏讹，如果發(fā)現(xiàn)它還有虛引用，就會在回收對象的內(nèi)存之前畜吊，把這個虛引用加入到與之關(guān)聯(lián)的引用隊列中泽疆。
Q：類加載的全過程是怎樣的？什么是雙親委派模型玲献？
- 技術(shù)點：類加載機制殉疼、雙親委派模型
- 思路：類加載機制的含義以及每個階段的作用，在解釋雙親委派模型之前需要先理解類加載器捌年，詳見要點提煉| 理解JVM之類加載機制
- 參考回答：
- （1）類加載機制：是虛擬機把描述類的數(shù)據(jù)從Class文件加載到內(nèi)存瓢娜，并對數(shù)據(jù)進行校驗、轉(zhuǎn)換解析和初始化礼预，最終形成可被虛擬機直接使用的Java類型的過程眠砾。另外，類型的加載托酸、連接和初始化過程都是在程序運行期完成的褒颈，從而通過犧牲一些性能開銷來換取Java程序的高度靈活性。下面介紹類加載每個階段的任務(wù)：
- 加載（Loading）：通過類的全限定名來獲取定義此類的二進制字節(jié)流励堡；將該二進制字節(jié)流所代表的靜態(tài)存儲結(jié)構(gòu)轉(zhuǎn)化為方法區(qū)的運行時數(shù)據(jù)結(jié)構(gòu)谷丸，該數(shù)據(jù)存儲數(shù)據(jù)結(jié)構(gòu)由虛擬機實現(xiàn)自行定義；在內(nèi)存中生成一個代表這個類的java.lang.Class對象应结，它將作為程序訪問方法區(qū)中的這些類型數(shù)據(jù)的外部接口
- 驗證（Verification）：確保Class文件的字節(jié)流中包含的信息符合當前虛擬機的要求刨疼，包括文件格式驗證、元數(shù)據(jù)驗證鹅龄、字節(jié)碼驗證和符號引用驗證
- 準備（Preparation）：為類變量分配內(nèi)存揩慕，因為這里的變量是由方法區(qū)分配內(nèi)存的，所以僅包括類變量而不包括實例變量扮休，后者將會在對象實例化時隨著對象一起分配在Java堆中迎卤；設(shè)置類變量初始值，通常情況下零值
- 解析（Resolution）：虛擬機將常量池內(nèi)的符號引用替換為直接引用的過程
- 初始化（Initialization）：是類加載過程的最后一步肛炮，會開始真正執(zhí)行類中定義的Java字節(jié)碼止吐。而之前的類加載過程中宝踪，除了在『加載』階段用戶應(yīng)用程序可通過自定義類加載器參與之外，其余階段均由虛擬機主導和控制
- （2）類加載器：不僅用于加載類碍扔，還和這個類本身一起作為在JVM中的唯一標識瘩燥。常見類加載器類型有：
- 啟動類加載器：是虛擬機自身的一部分
- 擴展類加載器、應(yīng)用程序類加載器不同、自定義類加載器：獨立于虛擬機外部
- （3）雙親委派模型：表示類加載器之間的層次關(guān)系厉膀。
- 前提：除了頂層啟動類加載器外，其余類加載器都應(yīng)當有自己的父類加載器二拐，且它們之間關(guān)系一般不會以繼承（Inheritance）關(guān)系來實現(xiàn)服鹅，而是通過組合（Composition）關(guān)系來復用父加載器的代碼。
- 工作過程：若一個類加載器收到了類加載的請求百新，它先會把這個請求委派給父類加載器企软，并向上傳遞，最終請求都傳送到頂層的啟動類加載器中饭望。只有當父加載器反饋自己無法完成這個加載請求時仗哨，子加載器才會嘗試自己去加載。
Q：工作內(nèi)存和主內(nèi)存的關(guān)系铅辞？在Java內(nèi)存模型有哪些可以保證并發(fā)過程的原子性厌漂、可見性和有序性的措施？
- 技術(shù)點：JVM內(nèi)存模型斟珊、線程安全
- 思路：理解Java內(nèi)存模型的結(jié)構(gòu)苇倡、詳見要點提煉| 理解JVM之內(nèi)存模型&線程
- 參考回答：Java內(nèi)存模型就是通過定義程序中各個變量的訪問規(guī)則，即在虛擬機中將變量存儲到內(nèi)存和從內(nèi)存中取出變量這樣的底層細節(jié)囤踩。
- 模型結(jié)構(gòu)如圖：
其中 旨椒，主內(nèi)存（Main Memory）是所有變量的存儲位置，每條線程還有自己的工作內(nèi)存高职，用于保存被該線程使用到的變量的主內(nèi)存副本拷貝钩乍。為了獲取更好的運行速度，虛擬機可能會讓工作內(nèi)存優(yōu)先存儲于寄存器和高速緩存中怔锌。- 保證并發(fā)過程的原子性、可見性和有序性的措施：
- 原子性（Atomicity）：一個操作要么都執(zhí)行要么都不執(zhí)行变过。
- 可直接保證的原子性變量操作有：
read埃元、load、assign媚狰、use岛杀、store和write，因此可認為基本數(shù)據(jù)類型的訪問讀寫是具備原子性的崭孤。- 若需要保證更大范圍的原子性类嗤，可通過更高層次的字節(jié)碼指令
monitorenter和monitorexit來隱式地使用lock和unlock這兩個操作糊肠，反映到Java代碼中就是同步代碼塊synchronized關(guān)鍵字。- 可見性（Visibility）：當一個線程修改了共享變量的值遗锣，其他線程能夠立即得知這個修改货裹。
- 通過在變量修改后將新值同步回主內(nèi)存，在變量讀取前從主內(nèi)存刷新變量值這種依賴主內(nèi)存作為傳遞媒介的方式來實現(xiàn)精偿。
- 提供三個關(guān)鍵字保證可見性：
volatile能保證新值能立即同步到主內(nèi)存弧圆，且每次使用前立即從主內(nèi)存刷新；synchronized對一個變量執(zhí)行unlock操作之前可以先把此變量同步回主內(nèi)存中笔咽；被final修飾的字段在構(gòu)造器中一旦初始化完成且構(gòu)造器沒有把this的引用傳遞出去搔预，就可以在其他線程中就能看見final字段的值。- 有序性（Ordering）：程序代碼按照指令順序執(zhí)行叶组。
- 如果在本線程內(nèi)觀察拯田，所有的操作都是有序的，指“線程內(nèi)表現(xiàn)為串行的語義”甩十；如果在一個線程中觀察另一個線程船庇，所有的操作都是無序的，指“指令重排序”現(xiàn)象和“工作內(nèi)存與主內(nèi)存同步延遲”現(xiàn)象枣氧。
- 提供兩個關(guān)鍵字保證有序性：
volatile本身就包含了禁止指令重排序的語義溢十；synchronized保證一個變量在同一個時刻只允許一條線程對其進行l(wèi)ock操作，使得持有同一個鎖的兩個同步塊只能串行地進入达吞。
Q：JVM张弛、Dalvik、ART的區(qū)別酪劫？
- 技術(shù)點：虛擬機對比
- 思路：分別談?wù)凧VM和Dalvik吞鸭、Dalvik和ART的區(qū)別，詳見Jvm覆糟、Dalvik和Art的區(qū)別
- 參考回答：
- Dalvik ：是Google公司自己設(shè)計用于Android平臺的Java虛擬機刻剥，不是Java虛擬機，沒有遵循Java虛擬機規(guī)范滩字，具體區(qū)別如下圖：
- ART：代替Dalvik造虏，應(yīng)用無需每次運行都要先編譯，而是在安裝時就預(yù)編譯字節(jié)碼到機器語言麦箍，提升運行時效率漓藕；預(yù)先編譯也使得ART占用空間比Dalvik大，即用空間換時間挟裂；由于減少運行時重復編譯享钞，可明顯改善電池續(xù)航，降低了能耗诀蓉。
Q：Java中堆和棧的區(qū)別栗竖？
- 技術(shù)點：內(nèi)存管理
- 思路：從存放數(shù)據(jù)和內(nèi)存回收角度出發(fā)
- 參考回答： 在java中暑脆，堆和棧都是內(nèi)存中存放數(shù)據(jù)的地方，具題區(qū)別是：
- 棧內(nèi)存：主要用來存放基本數(shù)據(jù)類型和局部變量狐肢；當在代碼塊定義一個變量時會在棧中為這個變量分配內(nèi)存空間添吗，當超過變量的作用域后這塊空間就會被自動釋放掉。
- 堆內(nèi)存：用來存放運行時創(chuàng)建的對象处坪，比如通過new關(guān)鍵字創(chuàng)建出來的對象和數(shù)組根资；需要由Java虛擬機的自動垃圾回收器來管理。
1.5 操作系統(tǒng)
Q：操作系統(tǒng)中進程和線程的區(qū)別同窘？
- 技術(shù)點：進程玄帕、線程
- 參考回答：
- 進程是操作系統(tǒng)分配和管理資源的單位，線程是CPU調(diào)度和管理的單位想邦，是CPU調(diào)度的最小單元
- 進程擁有獨立的地址空間裤纹，而線程間共享地址空間
- 進程創(chuàng)建的開銷比較大，線程創(chuàng)建的開銷小
- 引申：可談?wù)劙沧肯到y(tǒng)中對進程和線程的理解
Q：進程死鎖的產(chǎn)生和避免?
- 技術(shù)點：死鎖
- 思路：可從死鎖含義丧没、產(chǎn)生條件鹰椒、解決辦法、避免手段出發(fā)
- 參考回答：死鎖是指多個進程因循環(huán)等待資源而造成無法執(zhí)行的現(xiàn)象呕童，它會造成進程無法執(zhí)行漆际，同時會造成系統(tǒng)資源的極大浪費。
- 死鎖產(chǎn)生的條件：
- 互斥使用：指進程對所分配到的資源進行排它性使用夺饲，即在一段時間內(nèi)某資源只由一個進程占用奸汇。如果此時還有其它進程請求資源，則請求者只能等待往声，直至占有資源的進程用畢釋放擂找。
- 不可搶占：指進程已獲得的資源，在未使用完之前浩销，不能被剝奪贯涎，只能在使用完時由自己釋放。
- 請求和保持：指進程已經(jīng)保持至少一個資源慢洋，但又提出了新的資源請求塘雳，而該資源已被其它進程占有，此時請求進程阻塞普筹，但又對自己已獲得的其它資源保持不放粉捻。
- 循環(huán)等待：指在發(fā)生死鎖時，必然存在一個進程——資源的環(huán)形鏈斑芜，即進程集合{P0，P1祟霍，P2杏头，···盈包，Pn}中的P0正在等待一個P1占用的資源；P1正在等待P2占用的資源醇王，……呢燥，Pn正在等待已被P0占用的資源。
- 解決死鎖的策略：
- 銀行家算法：判斷此次請求是否造成死鎖若會造成死鎖寓娩，否則拒絕該請求
- 鴕鳥算法：忽略該問題叛氨，常用于在極少發(fā)生死鎖的的情況
- 死鎖的避免：通過合理的資源分配算法來確保永遠不會形成環(huán)形等待的封閉進程鏈，即“如果一個進程的當前請求的資源會導致死鎖棘伴，系統(tǒng)拒絕啟動該進程寞埠；如果一個資源的分配會導致下一步的死鎖，系統(tǒng)就拒絕本次的分配”
1.6 數(shù)據(jù)結(jié)構(gòu)&算法
Q：怎么理解數(shù)據(jù)結(jié)構(gòu)焊夸？
Q：什么是斐波那契數(shù)列仁连？
Q：迭代和遞歸的特點，并比較優(yōu)缺點
Q：了解哪些查找算法阱穗，時間復雜度都是多少饭冬？
Q：了解哪些排序算法，并比較一下揪阶，以及適用場景
Q：快排的基本思路是什么昌抠？最差的時間復雜度是多少？如何優(yōu)化鲁僚？
Q：AVL樹插入或刪除一個節(jié)點的過程是怎樣的炊苫？
Q：什么是紅黑樹？
Q：100盞燈問題
Q：老鼠和毒藥問題蕴茴，加個條件劝评，必須要求第二天出結(jié)果
Q：海量數(shù)據(jù)問題
Q：（手寫算法）二分查找
Q：（手寫算法）反轉(zhuǎn)鏈表
Q：（手寫算法）用兩個棧實現(xiàn)隊列
Q：（手寫算法）多線程輪流打印問題
Q：（手寫算法）如何判斷一個鏈有環(huán)/兩條鏈交叉
Q：（手寫算法）快速從一組無序數(shù)中找到第k大的數(shù)/前k個大的數(shù)
Q：（手寫算法）最長（不）重復子串
- 技術(shù)點：數(shù)據(jù)結(jié)構(gòu)、手寫算法
- 思路：篇幅問題倦淀，該部分將單獨做一篇總結(jié)
1.7 設(shè)計模式
Q：談?wù)凪VC蒋畜、MVP和MVVM，好在哪里撞叽，不好在哪里姻成？
- 技術(shù)點：MVC、MVP愿棋、MVVM
- 思路：詳見MVP科展、MVVM模式
- 參考回答：
- MVP的含義：
- Model：數(shù)據(jù)層，負責存儲糠雨、檢索才睹、操縱數(shù)據(jù)。
- View：UI層，顯示數(shù)據(jù)琅攘，并向Presenter報告用戶行為代态。
- Presenter：作為View與Model交互的中間紐帶牍汹，從Model拿數(shù)據(jù)，應(yīng)用到UI層，管理UI的狀態(tài)再悼，響應(yīng)用戶的行為逛腿。
- MVP相比于MVC的優(yōu)勢：
- 分離了視圖邏輯和業(yè)務(wù)邏輯匀伏，降低了耦合蜘醋。
- Activity只處理生命周期的任務(wù)，代碼變得更加簡潔荧关。
- 視圖邏輯和業(yè)務(wù)邏輯分別抽象到了View和Presenter的接口中去溉奕，提高代碼的可閱讀性。
- Presenter被抽象成接口羞酗，可以有多種具體的實現(xiàn)腐宋，所以方便進行單元測試。
- 把業(yè)務(wù)邏輯抽到Presenter中去檀轨，避免后臺線程引用著Activity導致Activity的資源無法被系統(tǒng)回收從而引起內(nèi)存泄露和OOM胸竞。
- MVVM的含義：與MVP類似，利用數(shù)據(jù)綁定(Data Binding)参萄、依賴屬性(Dependency Property)卫枝、命令(Command)、路由事件(Routed Event)等新特性讹挎，打造了一個更加靈活高效的架構(gòu)校赤。
- MVVM相比于MVP的優(yōu)勢：在常規(guī)的開發(fā)模式中，數(shù)據(jù)變化需要更新UI的時候筒溃，需要先獲取UI控件的引用马篮，然后再更新UI，獲取用戶的輸入和操作也需要通過UI控件的引用怜奖，但在MVVM中浑测，這些都是通過數(shù)據(jù)驅(qū)動來自動完成的，數(shù)據(jù)變化后會自動更新UI歪玲，UI的改變也能自動反饋到數(shù)據(jù)層迁央，數(shù)據(jù)成為主導因素。這樣MVVM層在業(yè)務(wù)邏輯處理中只要關(guān)心數(shù)據(jù)滥崩，不需要直接和UI打交道岖圈，在業(yè)務(wù)處理過程中簡單方便很多。
Q：如何理解生產(chǎn)者消費者模型钙皮？
- 技術(shù)點：生產(chǎn)者消費者模型
- 參考回答：生產(chǎn)者消費者模型通過一個緩存隊列蜂科，既解決了生產(chǎn)者和消費者之間強耦合的問題顽决，又平衡了生產(chǎn)者和消費者的處理能力。
- 具體規(guī)則：生產(chǎn)者只在緩存區(qū)未滿時進行生產(chǎn)崇摄，緩存區(qū)滿時生產(chǎn)者進程被阻塞擎值；消費者只在緩存區(qū)非空時進行消費，緩存區(qū)為空時消費者進程被阻塞逐抑；當消費者發(fā)現(xiàn)緩存區(qū)為空時會通知生產(chǎn)者生產(chǎn)；當生產(chǎn)者發(fā)現(xiàn)緩存區(qū)滿時會通知消費者消費屹蚊。
- 實現(xiàn)關(guān)鍵：synchronized保證對象只能被一個線程占用厕氨；wait()讓當前線程進入等待狀態(tài)，并釋放它所持有的鎖汹粤；notify()¬ifyAll()喚醒一個（所有）正處于等待狀態(tài)的線程
Q：是否能從Android中舉幾個例子說說用到了什么設(shè)計模式命斧？
- 技術(shù)點：設(shè)計模式
- 參考回答：
- View事件分發(fā)：責任鏈模式
- BitmapFactory加載圖片：工廠模式
- Adapter：適配器模式
- Builder：建造者模式
- Adapter.notifyDataSetChanged()：觀察者模式
- Binder機制：代理模式
Q：裝飾模式和代理模式有哪些區(qū)別？
- 技術(shù)點：裝飾模式嘱兼、代理模式
- 參考回答：
- 使用目的不同：代理模式是給目標對象提供一個代理對象国葬，并由代理對象控制對目標對象的引用；裝飾模式是在不必改變原類文件和使用繼承的情況下芹壕，動態(tài)地擴展一個對象的功能
- 構(gòu)造不同：代理模式內(nèi)部保持對目標對象的引用汇四；裝飾模式是通過構(gòu)造函數(shù)傳參的方式得到目標對象
Q：實現(xiàn)單例模式有幾種方法？懶漢式中雙層鎖的目的是什么踢涌？兩次判空的目的又是什么通孽？
- 技術(shù)點：單例模式
- 參考回答：實現(xiàn)單例模式常見的兩種方式：
（1）懶漢式：延遲加載，同時也要保證多線程環(huán)境下會產(chǎn)生多個single對象（DCL）
public class Singleton {
private Singleton() {}
private volatile static Singleton instance;//第一層鎖：保證變量可見性
public static Singleton getInstance() {
if (single == null) {//第一次判空：無需每次都加鎖睁壁，提高性能
synchronized (Singleton.class) {//第二層鎖：保證線程同步
if (single == null) {//第二次判空:避免多線程同時執(zhí)行g(shù)etInstance()產(chǎn)生多個single對象
single = new Singleton();
}
}
}
return single;
}
}
（2）餓漢式：在類加載初始化時就創(chuàng)建好一個靜態(tài)的對象供外部使用
public class Singleton {
private Singleton() {}
private static Singleton single = new Singleton();
public static Singleton getInstance() {
return single;
}
}
Q：談?wù)劻私獾脑O(shè)計模式原則背苦？
- 技術(shù)點：設(shè)計模式原則
- 參考回答：
- 單一職責原則：一個類只負責一個功能領(lǐng)域中的相應(yīng)職責
- 開放封閉原則：對擴展開放，對修改關(guān)閉
- 依賴倒置原則：抽象不應(yīng)該依賴于細節(jié)潘明，細節(jié)應(yīng)當依賴于抽象行剂。換言之，要針對接口編程钳降，而不是針對實現(xiàn)編程
- 迪米特法則：應(yīng)該盡量減少對象之間的交互厚宰，如果兩個對象之間不必彼此直接通信，那么這兩個對象就不應(yīng)當發(fā)生任何直接的相互作用牲阁，如果其中的一個對象需要調(diào)用另一個對象的某一個方法的話固阁，可以通過第三者轉(zhuǎn)發(fā)這個調(diào)用
- 合成/聚合復用原則：要盡量使用合成/聚合，盡量不要使用繼承
1.8 數(shù)據(jù)庫
Q：數(shù)據(jù)庫中的事務(wù)了解嗎城菊？事務(wù)的四大特性备燃？
- 技術(shù)點：事務(wù)
- 參考回答：
- 事務(wù)是并發(fā)控制的單位，是用戶定義的一個操作序列凌唬。它指這些操作要么都做并齐，要么都不做漏麦，以便服務(wù)器保持數(shù)據(jù)的完整性。
- 事務(wù)通常是以BEGIN TRANSACTION開始况褪，以COMMIT或ROLLBACK結(jié)束撕贞。
- 事務(wù)的四大特性（ACID特性）：原子性（Atomicity）表示事務(wù)中包括的諸操作要么全做，要么全不做测垛；一致性（Consistency）表示事務(wù)執(zhí)行的結(jié)果必須是使數(shù)據(jù)庫從一個一致性狀態(tài)變到另一個一致性狀態(tài)捏膨；隔離性（Isolation）表示一個事務(wù)的執(zhí)行不能被其他事務(wù)干擾；持續(xù)性（Durability）表示一個事務(wù)一旦提交食侮，它對數(shù)據(jù)庫中數(shù)據(jù)的改變就應(yīng)該是永久性的
- 引申：談?wù)?a href="http://www.reibang.com/p/478c6dca1b74" target="_blank">數(shù)據(jù)庫事務(wù)的并發(fā)控制
Q：如何理解數(shù)據(jù)庫的范式号涯？
- 技術(shù)點：范式
- 思路：詳見實例講解數(shù)據(jù)庫的3大范式和5大約束
- 參考回答：
- 第一范式（1NF）：數(shù)據(jù)表中的每個字段必須是不可拆分的最小單元，即確保每一列的原子性
- 第二范式（2NF）：滿足1NF后锯七，要求表中的所有列链快，都必須依賴于主鍵，而不能有任何一列與主鍵沒有關(guān)系
- 第三范式（3NF）：必須先滿足第二范式眉尸，要求表中的每一列只與主鍵直接相關(guān)而不是間接相關(guān)域蜗，即表中的每一列只能依賴于主鍵
1.9 hr問題
Q：請簡單的自我介紹一下
- 可能意圖：開場白；短期內(nèi)快速了解候選人情況噪猾；考察表達能力和邏輯思維霉祸；是否有備而來；第一印象
- 思路：說亮點畏妖、語言精煉脉执、熟練回答
Q：談?wù)勴椖拷?jīng)歷，為什么會做戒劫，怎么做的半夷，遇到的難點？
Q：談?wù)剬嵙暯?jīng)歷迅细，做了什么巫橄，收獲有哪些？
Q：談?wù)剬W習Android的經(jīng)歷茵典，有哪些學習方法和技巧湘换？
Q：成績怎么樣？獎學金情況?
Q：學過哪些課程统阿？那門課印象最深刻/最有意義/學的最好/最不喜歡彩倚？為什么？
Q：學習生活中遇到什么挫折扶平，如何解決的帆离？
Q：家是哪里的？是獨生子女嗎结澄？從小的家庭環(huán)境如何哥谷？
Q：平常有哪些興趣愛好岸夯？大學參加了哪些校園活動？
Q：評價一下自己的優(yōu)缺點们妥？/用x個詞形容你自己猜扮。/別人都是怎樣評價你的？
Q：覺得自己博客寫的最好的文章是什么监婶？為什么旅赢？
Q：覺得自己的優(yōu)勢是什么？
- 可能意圖：了解候選人的性格压储、各方面特質(zhì)鲜漩，是否符合企業(yè)價值觀；了解其溝通表達能力集惋、學習能力等才能，是否具有可塑性
- 思路：結(jié)合具體實例體現(xiàn)自己確是企業(yè)想要的人才
Q：是否會考研踩娘？/為何不保研刮刑？
Q：近x年的職業(yè)規(guī)劃？
Q：為什么想來我們公司养渴？/為何不轉(zhuǎn)正留在xx?
Q：對公司/部門是否有了解雷绢？
Q：為何會選擇做技術(shù)？/對女生做開發(fā)的看法理卑？
Q：還投過那些公司翘紊，進展如何？如果xx和xx都給你發(fā)offer會如何選擇藐唠？
Q：有男/女朋友嗎帆疟？未來有什么規(guī)劃？
Q：如何看待加班宇立？
Q：意向工作城市是哪踪宠？/是否會考慮在xx發(fā)展?
Q：對于薪酬有什么想法？
- 可能意圖：了解候選人對企業(yè)的意向度和忠誠度妈嘹，是否值得給發(fā)offer
- 思路：表現(xiàn)出想去該公司的態(tài)度柳琢、并已為之做了準備
Q：有什么問題想要問我？
- 可能意圖：結(jié)束語润脸；主動權(quán)交由候選人
- 思路：咨詢和崗位&部門&公司發(fā)展相關(guān)的情況柬脸、探討對某技術(shù)的看法、詢問面試官對你的評價毙驯、尋求學習等方面的建議倒堕、了解后續(xù)面試流程和進度；注意尔苦，避免問薪資和加班問題涩馆、也不要直接說“沒有問題”
1.10 項目相關(guān)行施、實習相關(guān)技術(shù)問題（略）
Q：使用那些版本控制工具？Git和SVN的區(qū)別魂那？
- 技術(shù)點：版本控制工具
- 參考回答：Git和SVN的區(qū)別有以下幾點：
- Git是分布式的蛾号，而SVN是集中式的（核心區(qū)別）
- Git按元數(shù)據(jù)方式存儲內(nèi)容，而SVN按文件存儲內(nèi)容
- 在Git上每個工作成員可以任意在自己的本地版本庫開啟無限個分支且互不影響涯雅，而對于SVN分支是一個完整的目錄且這個目錄擁有完整的實際文件
- Git沒有一個全局的版本號鲜结，而SVN有
- Git 的內(nèi)容完整性要優(yōu)于SVN
- 在Git中的絕大多數(shù)操作都只需要訪問本地文件和資源，不必聯(lián)網(wǎng)就可以看到所有的歷史版本記錄活逆，而SVN 卻需要聯(lián)網(wǎng)
- 引申：談?wù)剝煞N版本控制工具的優(yōu)缺點：SVN與GIT的優(yōu)缺點對比
Q：了解Git工具嗎精刷？用過哪些命令？解決沖突時git merge和git rebase的區(qū)別蔗候？
- 技術(shù)點：版本控制工具Git
- 思路：通過圖記憶Git常用命令怒允，詳見Git、GitHub锈遥、Stash
- 參考回答： 常用命令見圖纫事，源自一篇文章，教你學會Git
合并用到的命令git merge與git rebase的區(qū)別是所灸，git merge會生成一個新的節(jié)點丽惶，并將之前的提交分開顯示；git rebase操作不會生成新的節(jié)點爬立，而是將兩個分支融合成一個線性的提交钾唬。
（持續(xù)更新...）
2.彩蛋時刻
之前因一篇總結(jié)文獲得各路大佬的喜愛，很是受寵若驚侠驯，更有前輩愿與小白我切磋交流抡秆，實在不敢當。深知自己才疏學淺陵霉，還需再接再厲琅轧，以下都是個人拙見，如有不當踊挠，還請包涵乍桂。
Q：有關(guān)個人背景
之前有簡單介紹過，這里再具體下效床，更加深刻意識到自己的菜orz睹酌。我妹子一只，現(xiàn)在大連理工大學讀大四剩檀，明年畢業(yè)憋沿，專業(yè)是信息管理與信息系統(tǒng)，屬于管理學院沪猴，由于非科班辐啄，少學一些專業(yè)課采章，尤其算法很渣。
很多人好奇為什么一個妹子選擇做開發(fā)壶辜，其實是學長帶坑的hhh悯舟，當然我還會堅持把這個坑挖的更深，至少做技術(shù)是一定的砸民，畢竟對此還是饒有興趣抵怎。但隨著技術(shù)的日新月異，將來在哪條路上繼續(xù)另當別論了岭参。
Q：有關(guān)學習經(jīng)歷/推薦書目/面試準備
這部分內(nèi)容詳見春招總結(jié)：2018Android暑期實習面試總結(jié)反惕。
關(guān)于校招面試多做些補充，主要是常常聽到一些同學會埋怨演侯，“為何筆試多少多少AC卻沒面試通知姿染？”、“為何面試問題基本都回答上來卻不通過秒际？”盔粹。
對于前一個問題強調(diào)很多次，筆試成績只作參考程癌，面試官還會綜合簡歷去決定是否愿意對你發(fā)起面試，因此簡歷的作用不言而喻轴猎。好簡歷的幾個必備點：排版美觀嵌莉、重點突出、語言精煉捻脖、一頁紙锐峭、充分展示個人亮點（博客&Github、學歷&成績&實驗室可婶、實習&項目沿癞、競賽&論文&榮譽獎勵......）。如果說不清楚實習&項目的情況矛渴，建議分條列舉出重要的技術(shù)點（+影響力）椎扬。
對于后一個問題，可能的原因有：硬實力足夠但是軟實力欠缺具温，是否有良好的溝通表達能力蚕涤、積極向上的性格、端正的學習態(tài)度等等铣猩；再就是缺少一點運氣揖铜，除了客觀因素比如崗位競爭激烈、候選者又很厲害达皿、崗位hc還少天吓，再就是眼緣等主觀感受贿肩。
所以不得不說我能有好成績真的很走運，今年校招不少廠子缺移動端簡歷龄寞，反而算法崗過熱汰规，相對競爭小機會大；加上快人一步萄焦，提前上車控轿，搶先奪個好印象。
再多說一句拂封，之前的總結(jié)文針對的都是校招面試茬射，可見側(cè)重于基礎(chǔ)；而社招面試大多針對有工作經(jīng)驗的求職者冒签，更偏向項目&場景在抛、考察工程思維，側(cè)重點會稍有不同萧恕，當然還是因面試官而異了刚梭。
Q：面試中算法考察的難度
雖說工作后確實很少需要算法，但作為考察手寫代碼能力的一項指標票唆，算法題還是必不可少的朴读。那就有人就會問對于移動端開發(fā)崗算法題難度如何，只能說因為我水平太菜走趋，校招時面試官都很好并沒有太為難衅金，但自認為最基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)、還有劍指offer是要刷的吧簿煌，所以這也是后期學習的一個小目標氮唯。學有余力如果能再來個LeetCode就更好了。
Q：文章的排版&作圖
我的筆記都是用標記語言Markdown編輯的姨伟，美觀且容易上手惩琉，各大博客也大多支持Markdown在線編輯文章。如若需要離線夺荒，可參考早前的一篇博客MarkdownPad 2在win10上安裝及破解瞒渠、MacBook推薦用MacDown。
不少文章會有配圖般堆，有些取自他人技術(shù)文在孝，會標明出處，還有些就是用Photoshop和ProcessOn渣技術(shù)作圖的淮摔，若有好的作圖產(chǎn)品歡迎推薦私沮！
Q：學習習慣小分享
會有簡友在看完我的博客后，覺得我一定是沒日沒夜地埋頭苦學才有如此學習成果。其實不然仔燕，實則“小懶蟲”一個造垛，犯困的時候一定會小憩一下，并不是所謂的早睡早起的好孩子晰搀。這里就簡單談?wù)勎业摹皩W習理論”吧五辽！
一來自認為只有精神好才能集中注意力、更專注才能高效率（睡懶覺的借口）外恕，事實證明在大多數(shù)環(huán)境下杆逗，我都能聚精會神地做事情，進而高效利用時間鳞疲；
二來就是摸索出一套適合自己的學習法罪郊，即“系統(tǒng)學習+總結(jié)歸納+理解記憶+定時復習”，看起來很簡單但如果能配合好往往能事半功倍尚洽；
三來就是從小就有做學習計劃的習慣悔橄，無論是上學還是放假，大學還特意為自己做了個記事APP腺毫。但能100%完成計劃并非一蹴而就之事癣疟，還需要鍛煉這些能力：充分了解自己實力、擺脫拖延癥潮酒、可靈活變通睛挚，即既是計劃者又是執(zhí)行者。
總之用得當?shù)挠媱澕崩琛⒏咝У膶W習技巧竞川、加上專注力，不斷給學習的小火車助力叁熔，加速前進。當然適合自己的學習習慣才是最好的床牧，不要一味地模仿別人荣回，而是用實踐出真知，何況好習慣是長期培養(yǎng)出來的戈咳。
Q：最終去向心软？
經(jīng)過慎重的考慮，最終決定去了深圳騰訊（主要因為男票也在那hhh）
Q：想和我交流著蛙？
無公眾號無交流群删铃，另有CSDN和掘金賬號，ID踏堡、發(fā)表的文章和簡書都是一樣的猎唁，Github上沒什么有價值的東西orz，后續(xù)會進一步開發(fā)......
有問題歡迎在評論區(qū)留言顷蟆，如有必要也會在文中統(tǒng)一回復诫隅；想和我私下交流可私戳或者評論腐魂，發(fā)現(xiàn)私下留聯(lián)系方式的學習交流效果并不好，所以暫時不接受好友請求了逐纬，在這里謝謝大家的支持蛔屹！
