Java 程序員 面試前必備知識(shí)

前言

準(zhǔn)備了接近兩個(gè)月的面試筆試，現(xiàn)在終于是可以休息下了。真真是應(yīng)了那句老話“臺(tái)上一分鐘， 臺(tái)下十年功?！?。

人嘛，越努力，才會(huì)越幸運(yùn)。機(jī)會(huì)總是留給有準(zhǔn)備的人的。

下面分享一下我的Java實(shí)習(xí)生準(zhǔn)備所看過的材料，（雖然至今還有些依然看不懂地方。） 希望對(duì)這方面的同學(xué)有點(diǎn)幫助。

正文

自我介紹

先針對(duì)自己的情況寫段自我介紹，真實(shí)一些就好了，這方面我倒是沒有什么其他的建議。我就寫了我自己的真實(shí)的情況，比如喜歡寫博客，喜歡學(xué)習(xí)新技術(shù)，做過哪些小工具什么的。

但是有一點(diǎn)，那就是別作假，否則的話很容易被發(fā)現(xiàn)的，而且后果一般會(huì)很嚴(yán)重。

數(shù)據(jù)結(jié)構(gòu)和算法

這段時(shí)間自己也總結(jié)了關(guān)于數(shù)據(jù)結(jié)構(gòu)和算法相關(guān)的一些例子。也看了幾本書，總的來說《劍指Offer》挺好，就我不多的面試經(jīng)驗(yàn)來看，大部分面試官都是面試的上面的題，所以有時(shí)間的同學(xué)可以好好參考參考。

原書是使用C++實(shí)現(xiàn)的，我又用Python實(shí)現(xiàn)了其中大部分的內(nèi)容，有興趣的話可以參考我的GitHub： https://github.com/guoruibiao/sword-to-offer

由于本人經(jīng)驗(yàn)，技術(shù)能力有限，有不恰當(dāng)，不正確的地方還望批評(píng)指正。覺得還可以的也可以給我點(diǎn)個(gè)star，(__) 嘻嘻……

阿里的那個(gè)《技術(shù)之瞳》我也看了，里面內(nèi)容比較多，但是也比較亂。知識(shí)面很廣，但是我感覺深度上還是不太夠。不是很適合我。

其他的類似于Java面試寶典啊這些的，復(fù)習(xí)的時(shí)候認(rèn)真看一遍，就可以扔一邊了。但是前提是認(rèn)真看了，因?yàn)榛A(chǔ)沒打牢的話，更別提生層建筑了。于乎微處見真章。

Java篇

  • 集合詳解

    • 集合類的線程安全總結(jié)：
      • 安全的： Vector， Hashtable, concurrentHashMap...
      • 不安全的：HashMap, ArrayList, TreeMap, linkedList,HashSet(底層基于HashMap實(shí)現(xiàn))
    • 容量相關(guān)：
      • Vector默認(rèn)初始容量為10， 自增長量為0。翻倍增長拓展機(jī)制。
      • ArrayList:默認(rèn)為10，最大上限為Integer。MAX_SIZE-8；拓展機(jī)制：newCapacity = oldCapacity + (oldCapacity >> 1);
      • Hashtable：默認(rèn)大小為11， 裝載因子為0.75
      • HashMap： 默認(rèn)16，裝載因子0.75， 最大上限1<<30
  • Comparator和Comparable的區(qū)別
一個(gè)類實(shí)現(xiàn)了Camparable接口則表明這個(gè)類的對(duì)象之間是可以相互比較的，這個(gè)類對(duì)象組成的集合就可以直接使用sort方法排序。 
        Comparator可以看成一種算法的實(shí)現(xiàn)，將算法和數(shù)據(jù)分離，Comparator也可以在下面兩種環(huán)境下使用： 
        Comparable 接口以提供自然排序順序。

        對(duì)于那些沒有自然順序的類、或者當(dāng)您想要一個(gè)不同于自然順序的順序時(shí)，您可以實(shí)現(xiàn) 
        Comparator 接口來定義您自己的排序函數(shù)?？梢詫omparator傳遞給Collections.sort或Arrays.sort。

        Comparator接口 
        當(dāng)一個(gè)類并未實(shí)現(xiàn)Comparable，或者不喜歡缺省的Comaparable行為?？梢詫?shí)現(xiàn)Comparator接口
        直接實(shí)現(xiàn)Comparator的compare接口完成自定義比較類。
        例：Arrays.sort(results, new Comparator<RepDataQueryResultVO/>() 數(shù)組排序 RepDataQueryExecutor
        例：Collections.sort(lst,new Comparator<TaskPrintSchemeVO/>()

  • Java 的instanceof關(guān)鍵字底層實(shí)現(xiàn)：

    維護(hù)了主要超類型（繼承深度）小于7的主數(shù)組， 和次要超類型（判斷的時(shí)候需要super鏈遍歷查找）；在字節(jié)碼使用特殊指令對(duì)常量池中的相關(guān)符號(hào)引用進(jìn)行判斷，來決定true和false。

  • Java內(nèi)存模型

    • 年輕代，： 伊甸區(qū)，兩個(gè)存活區(qū)（總有一個(gè)為空，輪詢轉(zhuǎn)移）。 （逐級(jí)晉升機(jī)制）

    • 年老代： 在年輕代中經(jīng)歷了N次垃圾回收后依然存活的生命期較長的對(duì)象。

    • 永久代： 存放靜態(tài)文件，如Java類，方法等。持久代對(duì)垃圾回收沒有顯著影響。

  • GC 觸發(fā)機(jī)制：

    • 新生代GC： 在新對(duì)象生成且在伊甸區(qū)申請(qǐng)空間失敗的時(shí)候會(huì)觸發(fā)一次對(duì)伊甸區(qū)的GC，把
      存活的對(duì)象放置到存活區(qū)。通常來說伊甸區(qū)的GC會(huì)比較頻繁。

    • Full GC： 對(duì)整個(gè)堆進(jìn)行整理，速度慢，次數(shù)少。觸發(fā)的時(shí)機(jī)： 年輕代被寫滿， 持久代被寫滿，系統(tǒng)GC被調(diào)用。

  • GC 回收標(biāo)準(zhǔn)：

    • 引用計(jì)數(shù)算法： 可能導(dǎo)致循環(huán)引用導(dǎo)致GC效果不好，代替方式有引用標(biāo)記清理方式

    • 根搜索算法： 那些對(duì)象可以作為GC Root？ 答案是虛擬機(jī)棧中引用的對(duì)象，方法區(qū)中的類靜態(tài)屬性引用的對(duì)象
      方法區(qū)中的常量引用的對(duì)象， 本地方法棧中JNI的引用對(duì)象

    • 引用狀態(tài)：強(qiáng)（被引用著）軟（還有些有那個(gè)但不是必須， 二次回收）弱（非必須對(duì)象，下次就回收）虛（告知被引用的對(duì)象，要被回收啦，作用不大）： 程度依次減小，

    • 方法區(qū)回收： JVM沒有強(qiáng)調(diào)方法區(qū)的回收，但是也是非常有用的，對(duì)于效率要求較高而言。對(duì)于廢棄常量比較好處理
      直接判斷有沒有相關(guān)的引用即可。對(duì)于無效類對(duì)象而言有下面幾種方式。該類的實(shí)例都被回收；該類的classLoader被回收；該類對(duì)應(yīng)的字節(jié)碼對(duì)象Class沒有被任何地方引用，無法在任何地方通過反射來訪問該類的方法。

  • GC 算法：

    • 標(biāo)記清除算法： 對(duì)要進(jìn)行回收的對(duì)象進(jìn)行標(biāo)記，在下次GC的時(shí)候予以回收。但是碎片化嚴(yán)重，對(duì)下次的大對(duì)象的分配效率不高。

    • 復(fù)制算法： 為了解決效率問題而出現(xiàn)，將內(nèi)存分為可用的兩塊，對(duì)于存活的對(duì)象

    •        進(jìn)行復(fù)制轉(zhuǎn)移，碎片化現(xiàn)象減輕。但是代價(jià)高啊，可用的只有一半，對(duì)于新生代內(nèi)存區(qū)采用比較頻繁，

    • 標(biāo)記整理算法： 對(duì)于老年代對(duì)象存活率高，這樣復(fù)制算法不適用，而采用標(biāo)記整理算法。將老年代中存活的對(duì)象移動(dòng)到一側(cè)，對(duì)另外的區(qū)域進(jìn)行GC。

      綜上所述，對(duì)不同的代區(qū)采用不同的GC算法，會(huì)使得GC的效率得到進(jìn)一步的提升。

  • 垃圾收集器： 針對(duì)比較常用的HotSpot虛擬機(jī)而言，支持不同類型的垃圾收集器。
    • Serial收集器。新生代中采用單線程的復(fù)制算法的垃圾收集器。Client端默認(rèn)
    • Parallel收集器。新生代中采用多線程的復(fù)制算法的垃圾收集器。Server端默認(rèn)，高吞吐量。
    • Serial Old收集器，采用單線程的標(biāo)記-整理算法的垃圾收集器，Client端使用。
    • Parallel Old收集器， 采用多線程的標(biāo)記-整理算法的垃圾收集器，Server端使用。
    • CMS（Concurrent-Mark-Sweep）,以一種獲取最短回收停頓為時(shí)間目標(biāo)的老年代收集器，采用標(biāo)記-清除算法。
    • G1(Garbage-First),對(duì)新生代和老年代不予區(qū)分，而是對(duì)內(nèi)存堆空間劃分區(qū)塊，分配不同的優(yōu)先級(jí)，使用更有效率的垃圾回收算法。
  • 鎖相關(guān)：
    • 樂觀鎖機(jī)制
    • CAS（Compare And Swap）方法
    • 悲觀鎖：
      Synchronized就是悲觀鎖的一種，也稱之為獨(dú)占鎖，加了synchronized關(guān)鍵字的
      代碼基本上就只能以單線程的形式去執(zhí)行了，它會(huì)導(dǎo)致其他需要該資源的線程掛起，直到前面的線程執(zhí)行完畢釋放所資源。而另外一種樂觀鎖是一種更高效的機(jī)制，它的原理就是每次不加鎖去執(zhí)行某項(xiàng)操作，如果發(fā)生沖突則失敗并重試，直到成功為止，其實(shí)本 質(zhì)上不算鎖，所以很多地方也稱之為自旋。
  • ClassLoader相關(guān)：
    雙親委派模型，以及唯一性的好處。
    有哪些類加載器 （Bootstrap ClassLoader[C語言實(shí)現(xiàn)，很底層]， Ext.., Application）
  • 一些原則：
    • 小黃鴨測試法
    • happen-before原則
    • fail-fast原則
    • fail-safe原則
    • 開閉原則

Java EE知識(shí)點(diǎn)儲(chǔ)備

  • Spring中 IOC的生命周期：
（<3/>init-method，<1/>intilizingbean接口方法<2/>afterPropertiesSet的先后順序）等。

//詳情參考
Bean factory implementations should support the standard bean lifecycle interfaces as far as possible. The full set of initialization methods and their standard order is:  
        1. BeanNameAware's setBeanName  
        2. BeanClassLoaderAware's setBeanClassLoader  
        3. BeanFactoryAware's setBeanFactory  
        4. ResourceLoaderAware's setResourceLoader (only applicable when running in an application context)  
        5. ApplicationEventPublisherAware's setApplicationEventPublisher (only applicable when running in an application context)  
        6. MessageSourceAware's setMessageSource (only applicable when running in an application context)  
        7. ApplicationContextAware's setApplicationContext (only applicable when running in an application context)  
        8. ServletContextAware's setServletContext (only applicable when running in a web application context)  
          
        9. postProcessBeforeInitialization methods of BeanPostProcessors  
        10. InitializingBean's afterPropertiesSet  
        11. a custom init-method definition  
        12. postProcessAfterInitialization methods of BeanPostProcessors   
          
        On shutdown of a bean factory, the following lifecycle methods apply:  
        1. DisposableBean's destroy  
        2. a custom destroy-method definition

大致可以這么來理解：

bean容器創(chuàng)建--通過反射實(shí)現(xiàn)bean開始實(shí)例化--通過注入信息設(shè)置屬性--可以被調(diào)用啦--容器被銷毀/bean中設(shè)置的destory-method方法被調(diào)用實(shí)現(xiàn)bean的銷毀。

我自己的理解如下：

  • Strtus：
    首先是客戶端發(fā)起一個(gè)指向servlet容器的請(qǐng)求，被容器上一系列的過濾器獲得主要是ActionContextCleanUp
    然后被FilterDispatcher攔截到，經(jīng)過查詢ActionMapper之后決定調(diào)用哪個(gè)action
    FilterDispatcher將請(qǐng)求轉(zhuǎn)發(fā)給ActionProxy，ActionMapper內(nèi)部經(jīng)過查詢ConfigurationManager找到要調(diào)用的Action類
    ActionProxy代理產(chǎn)生一個(gè)ActionInvocation實(shí)例，回調(diào)action的execute方法，通過返回的串調(diào)用相關(guān)的jsp頁面
    最后反向經(jīng)過一系列的攔截器，釋放不需要的如ThreadLocal里面的數(shù)據(jù)，對(duì)象信息。

  • SpringMVC：
    前端管家DispatcherServlet接收來自客戶端的請(qǐng)求，然后通過handlerMapping查找到相應(yīng)的處理器。轉(zhuǎn)交給handler處理相應(yīng)的業(yè)務(wù)邏輯。處理結(jié)束后返回一個(gè)ModelAndView，返回給客戶端以響應(yīng)。

  • Servlet：
    web服務(wù)器接收到客戶端請(qǐng)求之后，將請(qǐng)求指向一個(gè)與url對(duì)應(yīng)的servlet的class，如果已實(shí)例化則調(diào)用init，service，destory。如果未創(chuàng)建，則通過查詢ServletConfig獲取到相關(guān)的字節(jié)碼信息，進(jìn)行實(shí)例化，接著進(jìn)行上面的操作。

  • Hibernate一二級(jí)緩存，以及l(fā)azy-load
    • 一級(jí)緩存： Hibernate內(nèi)置，默認(rèn)，切不可卸載
    • 二級(jí)緩存你：指SessionFactory的外部緩存，可配置可更改，可卸載。常用插件
    •  EhCache：可作為進(jìn)程范圍的緩存，存放數(shù)據(jù)的物理介質(zhì)可以是內(nèi)存或硬盤，對(duì)Hibernate的查詢緩存提供了支持。 
     memcache等。
    • 惰性加載： 通過延遲加載技術(shù)可以避免過多的，過早的加載表里面的數(shù)據(jù)，從而降低系統(tǒng)的內(nèi)存開銷。Hibernate中使用代理來實(shí)現(xiàn)這一個(gè)效果，要想使用在核心配置文件中對(duì)lazy-load屬性設(shè)值為true即可。
  • Spring AOP解決了什么問題？怎么實(shí)現(xiàn)的？aop與cglib，與asm的關(guān)系。

    • AOP實(shí)現(xiàn)了面向切面編程。連接點(diǎn)（可以被增強(qiáng)的方法），切入點(diǎn)（被增強(qiáng)的方法），增強(qiáng)（業(yè)務(wù)中增強(qiáng)的具體邏輯），切面（將增強(qiáng)應(yīng)用到切入點(diǎn)的過程）

    • AOP中借助于動(dòng)態(tài)代理或者cglib實(shí)現(xiàn)。動(dòng)態(tài)代理需要接口，cglib是子類增強(qiáng)機(jī)制，不能增強(qiáng)final類。

    • ASM是一個(gè)字節(jié)碼操作框架，直接修改產(chǎn)生字節(jié)碼數(shù)據(jù)流，效率高，但是人工需要對(duì)字節(jié)碼非常的熟悉。

  • Spring中的事務(wù)傳播屬性：
    • REQUESTED: 默認(rèn)，當(dāng)前不存在則新增一個(gè)事務(wù)。
    • MANDATORY：沒有事務(wù)則失敗
    • NEVER: 有事務(wù)則失敗
    • NOT_SUPPORT： 以非事務(wù)的形式執(zhí)行，如果當(dāng)前存在事務(wù)，則掛起
    • SUPPORT： 支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，則以非事務(wù)形式執(zhí)行
    • NESTED：支持當(dāng)前事務(wù)，新增savepoint，與當(dāng)前事務(wù)同步提交或者回滾，但是內(nèi)部事務(wù)出現(xiàn)異常時(shí)，不會(huì)影響當(dāng)前事務(wù)的回滾。簡單來說就是內(nèi)層操作依賴于外層的事務(wù)。
  • Spring中的BeanFactory和FactoryBean的區(qū)別：
    • BeanFactory使得管理任何性質(zhì)的類得以實(shí)現(xiàn)，ApplicationContext是BeanFactory的增強(qiáng)。
    • FactoryBean提供一個(gè)工廠方法，用來得到其他的bean實(shí)例。從FactoryBean上得到的bean與普通的bean的配置不同，因?yàn)椴皇怯扇萜鳟a(chǎn)生，所以不需要提供class屬性。如ProxyFactoryBean用于創(chuàng)建代理（根據(jù)advisor生成TargetBean的代理，得以實(shí)現(xiàn)增強(qiáng)行為）。

計(jì)算機(jī)網(wǎng)絡(luò)

  • HTTP協(xié)議， http1.0和http2.0區(qū)別：

    • http2的二進(jìn)制壓縮流，完全的多路傳輸。使用報(bào)頭壓縮降低了開銷；實(shí)現(xiàn)了推送，降低了客戶端多次請(qǐng)求。

    • 報(bào)文結(jié)構(gòu)---請(qǐng)求部分：
      請(qǐng)求行：請(qǐng)求方法+空格+URL+空格+協(xié)議版本+回車+換行符
      請(qǐng)求頭： 什么referer，userAgent啦等等
      空行： 回車符+換行符
      請(qǐng)求數(shù)據(jù)： 來自客戶端的請(qǐng)求的數(shù)據(jù)。

    • 報(bào)文結(jié)構(gòu)---響應(yīng)部分：
      狀態(tài)行：協(xié)議版本， 狀態(tài)碼啊啥的
      消息報(bào)頭：時(shí)間， content-type， content-length啥的
      響應(yīng)正文： 正文數(shù)據(jù)流。

  • 推送模式：

    • 長連接: 減少了客戶端輪詢的計(jì)算，但是對(duì)于服務(wù)器而言有一定壓力，且服務(wù)對(duì)象會(huì)變少。
    • 輪詢： 可以很快的監(jiān)聽到數(shù)據(jù)變化，但是計(jì)算代價(jià)較高。
    • websocket： 事件隊(duì)列模型，解決了上面的問題，服務(wù)器和客戶端都可作為主動(dòng)方。

    但是總的來說有兩大方向： Pull 和 Push； Push對(duì)于客戶端而言流量消耗更少；Pull對(duì)服務(wù)器端而言壓力稍小。

  • WebService淺析：
    • soap:簡單對(duì)象訪問協(xié)議，基于xm，可以和諸多應(yīng)用層協(xié)議一起工作，成本高，代價(jià)大。
    • rest：表屬性狀態(tài)轉(zhuǎn)移，是一個(gè)抽象的對(duì)于資源訪問的一套設(shè)計(jì)思路。安全性相比soap較低，但是更流行，成本低。
    • WSDL：web service description language.也就是哪個(gè)服務(wù)器以什么方式提供什么服務(wù)的意思，也即服務(wù)發(fā)現(xiàn)。工作流程：
      根據(jù)WSDL構(gòu)造一條soap語句發(fā)給服務(wù)器，獲取返回的soap數(shù)據(jù)并解碼為WSDL，獲取相應(yīng)服務(wù)。
對(duì)二者的思考，就是現(xiàn)在的rest也只是soap模式在rest下的借尸還魂，并沒有徹底的改變，而rest缺少一套標(biāo)準(zhǔn)，實(shí)現(xiàn)的方式也比較亂，各大廠商也不一致。需要時(shí)間的沉淀。

操作系統(tǒng)

  • 分頁和分段：
    操作系統(tǒng)分頁是為了更好的提高利用率，一個(gè)系統(tǒng)頁面大小是一定的，不可改變。而分段則是用戶決定的，來方便用戶
  • 進(jìn)程調(diào)度算法： 短作業(yè)優(yōu)先， 優(yōu)先級(jí)策略， 輪詢， 分級(jí)別的整合法。

數(shù)據(jù)庫相關(guān)

  • Memcache和Redis：

    • IO模型：memcache是多線程非阻塞IO，分為主監(jiān)聽和工作線程；redis則是單線程事件驅(qū)動(dòng)，效率更高一點(diǎn)。
    • 內(nèi)存分配： memcache是內(nèi)存預(yù)分配，碎片少，但有空間浪費(fèi)之嫌；
      redis是現(xiàn)場分配，碎片化現(xiàn)象存在，但是非臨時(shí)數(shù)據(jù)不會(huì)踢到磁盤，仍會(huì)留在內(nèi)存，素以更適合存儲(chǔ)而不是cache.
    • 數(shù)據(jù)一致性： memcache采用cas命令可以保證數(shù)據(jù)一致性；redis使用原子操作保證事務(wù)正常運(yùn)行。
    • 存儲(chǔ)方式： memcache使用key-value； redis除此之外還可以存儲(chǔ)list，map等數(shù)據(jù)結(jié)構(gòu)。

    總結(jié)：
    redis的最佳使用方式時(shí)全部數(shù)據(jù)in-memory.
    redis更多場景是作為memcache的替代品來使用。
    當(dāng)需要除了key-value之外的數(shù)據(jù)結(jié)構(gòu)支持的時(shí)候，redis更適合。
    當(dāng)存儲(chǔ)的數(shù)據(jù)不鞥唄剔除的時(shí)候，使用redis更合適。

  • 數(shù)據(jù)庫事務(wù)以及隔離級(jí)別：

    • 四大特性： ACID（原子性[要么都成功，要么全失敗]， 一致性[事務(wù)從一個(gè)狀態(tài)變成另一個(gè)一致性的狀態(tài)]， 隔離性[一個(gè)事務(wù)中的行為不會(huì)影響到另一個(gè)事務(wù)]， 持久性[改變了數(shù)據(jù)就不能再撤銷了]）。

    • 不考慮事務(wù)的時(shí)候有可能在讀取數(shù)據(jù)庫時(shí)發(fā)生如下問題：
      臟讀： 一個(gè)事務(wù)中讀取了另一個(gè)事務(wù)中未提交的數(shù)據(jù)。
      不可重復(fù)讀： 相同的sql語句，兩次讀取的結(jié)果不一致。
      幻讀： 一個(gè)事務(wù)讀取到了另一個(gè)事務(wù)提交后的結(jié)果，或者改變了本次事務(wù)的數(shù)據(jù)的結(jié)果。也稱為虛讀。

    • 隔離級(jí)別：

      • 未提交讀： 最低級(jí)別，任何情況都不能保證。
      • 提交讀： 可避免臟讀。
      • 重復(fù)讀： 可避免臟讀，不可重復(fù)讀（MySQL默認(rèn)支持?。?/li>
      • 序列化： 最強(qiáng)設(shè)置。

    事務(wù)的隔離級(jí)別越高，執(zhí)行的效率就會(huì)越低！在JDBC代碼中可以對(duì)connection對(duì)象設(shè)置相應(yīng)的隔離級(jí)別。

事務(wù)及隔離級(jí)別 詳解1

事務(wù)及隔離級(jí)別 詳解2

  • 數(shù)據(jù)庫數(shù)據(jù)結(jié)構(gòu)：
      1. mysql存儲(chǔ)引擎中索引的實(shí)現(xiàn)機(jī)制；使用B-Tree優(yōu)勢在于出度大，磁盤預(yù)讀效果好，與之相比，二叉樹，紅黑樹則不好。理論上來講，出度越大，索引的效率越高。盡量采用自增字段作為索引，因?yàn)榘错摯鎯?chǔ)的時(shí)候不需要移動(dòng)數(shù)據(jù)塊，而不重復(fù)的字段則類似于隨機(jī)方式，需要移動(dòng)數(shù)據(jù)塊，效率會(huì)差點(diǎn)。這就是因?yàn)閕nnodb的聚集特性（數(shù)據(jù)在磁盤上的存儲(chǔ)順序和索引順序一致）決定的。

    • 2.數(shù)據(jù)庫事務(wù)的幾種粒度；表鎖（不會(huì)產(chǎn)生死鎖，但是并發(fā)度低）， 頁鎖（有可能產(chǎn)生死鎖，但是用的不多）， 行鎖（并發(fā)度高，但是有可能產(chǎn)生死鎖）。

    • 3.行鎖，表鎖；樂觀鎖，悲觀鎖
      悲觀鎖：在讀取數(shù)據(jù)時(shí)鎖住那幾行，其他對(duì)這幾行的更新需要等到悲觀鎖結(jié)束時(shí)才能繼續(xù)
      樂觀鎖：讀取數(shù)據(jù)時(shí)不鎖，更新時(shí)檢查是否數(shù)據(jù)已經(jīng)被更新過，如果是則取消當(dāng)前更新
      一般在悲觀鎖的等待時(shí)間過長而不能接受時(shí)我們才會(huì)選擇樂觀鎖

  • innode的鎖，死鎖和 索引相關(guān)的東西。
    • 隔離級(jí)別： 未提交讀，提交讀， 重復(fù)讀，序列化（一次只有一個(gè)人可以操作）
    • innodb默認(rèn)采用行鎖，對(duì)數(shù)據(jù)采用repeatable read，也就是事務(wù)開始后讀取到的結(jié)果會(huì)一致，這和oracle的committed read（只能讀取提交的事務(wù)數(shù)據(jù)，有可能產(chǎn)生兩次結(jié)果不一致的問題）不同。
    • 行鎖并發(fā)度高，不易產(chǎn)生死鎖；表級(jí)鎖并發(fā)度低，不會(huì)產(chǎn)生死鎖。
    • 鎖本身又分為讀鎖和寫鎖； 按照共享與否大致分為共享鎖和排它鎖等四個(gè)。
  • mysql死鎖： 行級(jí)鎖并不是直接鎖行記錄，而是鎖索引（主鍵索引和非主鍵索引）。
    • 一條sql語句如操作了主鍵索引，則會(huì)鎖住此主鍵索引；操作了非主鍵索引，則先鎖住非主鍵索引，再鎖住主鍵索引。
    •       在update，delete操作時(shí)，mysql還會(huì)鎖住where下相鄰的記錄，實(shí)現(xiàn)next-key locking.
      可以很好的解決“幻讀”問題。
  • SQL 優(yōu)化入門
    • 使用內(nèi)部函數(shù)； 避免select*； 使用表的別名，提高效率和準(zhǔn)確度； 用[not]exist 代替[not]in; 使用索引；
    • 分表，分庫，精簡表結(jié)構(gòu)，字段結(jié)構(gòu)；等等。
    • SQL 優(yōu)化詳解

XML

DTD（Document Type Define，文檔定義類型）， schema（ XSD， XML Schema Document）之間的區(qū)別和聯(lián)系

  • DTD：采用非XML語法規(guī)范，拓展性差。命名沖突不易解決。
  • schema： 采用XML語法規(guī)范

常識(shí)性知識(shí)

  • 查找Linux中占用磁盤最大的文件：

du path -type f -size +NumberG | sort -n -r | head -n 10

找出給定目錄下以G為單位的最大的10個(gè)文件，并排序輸出。

  • 全局唯一ID問題：

    時(shí)間戳，加去中心化，加邏輯分片，機(jī)器號(hào)等

  • 什么是布隆過濾器，其實(shí)現(xiàn)原理是？ False positive指的是？
    • 布隆過濾器就是使用一個(gè)很大的數(shù)組，根據(jù)K個(gè)哈希函數(shù)得到K個(gè)位置，在數(shù)組中將這K個(gè)位置對(duì)應(yīng)的值設(shè)置為1；
    • 查詢的時(shí)候，仍舊采用這K個(gè)哈希函數(shù)對(duì)查詢串進(jìn)行哈希運(yùn)算，判斷對(duì)應(yīng)的K歌位置是否為1；有可能因?yàn)槠渌拇?/li>
    • 插入導(dǎo)致這K個(gè)位置全部為1，導(dǎo)致誤判現(xiàn)象的產(chǎn)生，不過這種情況發(fā)生的可能性很小，畢竟要與K個(gè)哈希位置都一致。
  • RPC的負(fù)載均衡、服務(wù)發(fā)現(xiàn)怎么做的
    - 單點(diǎn)LB： 容易出現(xiàn)單點(diǎn)失效問題，且需要配合DNS服務(wù)，性能開銷略大
    - LB集成到客戶端： 對(duì)于開發(fā)成本較大，平臺(tái)限制。但是對(duì)于服務(wù)發(fā)現(xiàn)和健康檢查而言，服務(wù)器端壓力減小。
    - LB作為主機(jī)單進(jìn)程，相當(dāng)于將LB進(jìn)程和服務(wù)進(jìn)程隔離開，一個(gè)主機(jī)掛了只影響單個(gè)主機(jī)服務(wù)，但是配置較為麻煩，環(huán)節(jié)多，出錯(cuò)調(diào)試較為困難。

  • Linux使用及問題排查：
    - grep，awk，sed； 是否自己寫過shell腳本；
    - 常見的cpu load過高，us過高，一般是什么問題。引申出是否用過top，jstat，jstack等。

    可以先ps -aux （或者top， htop）找到占比高的進(jìn)程號(hào)，然后使用ps -Lp 122427 cu找到對(duì)應(yīng)的java進(jìn)程的每個(gè)線程的CPU使用率，追蹤線程內(nèi)部運(yùn)行的狀況。
        常見的內(nèi)存問題一般有哪些。 引申出是否用過free，top， jmap等。
  
  詳解： http://blog.csdn.net/wisgood/article/details/25343845

總結(jié)

林林總總的一萬多字了，但是這還遠(yuǎn)遠(yuǎn)不能覆蓋全部。而且距離一個(gè)合格的Java程序員僅僅知道這些還遠(yuǎn)遠(yuǎn)不夠，我們能做的就是盡可能的讓自己接近那個(gè)標(biāo)準(zhǔn)吧。

上面這些鏈接也好，總結(jié)也好，大家還是需要有自己的理解。

“盡信書，則不如無書！”，其實(shí)也是這么個(gè)道理，帶著思考來閱讀，效率，效果都可能會(huì)更好。

最后，希望大家都能找到自己心儀的offer。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 從三月份找實(shí)習(xí)到現(xiàn)在，面了一些公司，掛了不少，但最終還是拿到小米、百度、阿里、京東、新浪、CVTE、樂視家的研發(fā)崗...
    時(shí)芥藍(lán)閱讀 42,752評(píng)論 11贊 349
  • 1. Java基礎(chǔ)部分 基礎(chǔ)部分的順序：基本語法，類相關(guān)的語法，內(nèi)部類的語法，繼承相關(guān)的語法，異常的語法，線程的語...
    子非魚_t_閱讀 34,623評(píng)論 18贊 399
  • Java8張圖 11、字符串不變性 12、equals()方法、hashCode()方法的區(qū)別 13、...
    Miley_MOJIE閱讀 3,885評(píng)論 0贊 11
  • 回看了之前自己寫的自我激勵(lì)，跟預(yù)售實(shí)戰(zhàn)得來的感受相比真是太過膚淺了。應(yīng)了陸游那句“紙上得來終覺淺 絕知此事要躬行”...
    Sunyoga閱讀 538評(píng)論 1贊 2
  • 人，時(shí)而強(qiáng)大時(shí)而渺小。人，時(shí)而堅(jiān)強(qiáng)時(shí)而墮落。有時(shí)覺得人的一生是為了什么？為了讓自己活下去？ 記得在上幼兒園的時(shí)候...
    虐雪閱讀 194評(píng)論 0贊 0

友情鏈接更多精彩內(nèi)容