java開發基礎知識

HashMap

• 1.HashMap線程不安全的緣由：在多線程狀況下，會致使hashmap出現鏈表閉環，一旦進入了閉環get數據，程序就會進入死循環，因此致使HashMap是非線程安全的。
• 2.多線程狀況下使用map的方案： 1）Collections.synchronizedMap 2）Hashtable 3)ConcurrentHashMap
• 3.使用場景：非併發操做下存儲鍵值對，防止出現鏈表閉環，致使cpu太高，系統崩潰。併發條件下使用Hashtable，但推薦使用ConcurrentHashMap，效率更高。

ConcurrentHashMap

• 1.實現原理：底層是使用段實現的，每一個段是一個Hashtable，Hashtable是線程安全的，當多個操做發生在不一樣的段上，就能夠併發執行，執行效率比Hashtable高
• 2.使用場景：併發操做下使用，效率比Hashtable高

List

• ArrayList: 1.數組結構 2.查找較快 3.增刪較慢 4.線程不安全
• LinkedList 1.鏈表結構 2.查找較慢 3.增刪較快 4.線程不安全
• Vector 1.數組結構 2.查找較快 3.增刪較慢 4.線程安全
• Stack 1.繼承Vector 2.線程安全
• 使用場景： 1.對於須要增刪的使用LinkedList 2.對於單線程須要查找的使用ArrayList 3.對於併發，只有單線程操做就使用ArrayList，對於多線程，併發操做列表的就使用Vector

NIO

• NIO的優勢：1.不用read或者write就能夠操做文件 2.採用虛擬內存技術，提升了IO的效率 3.修改自動flash到文件

線程

• 類鎖：synchroized修飾靜態方法，對該類的全部對象生效，同一時間只能有一個線程獲取該鎖，其餘線程則阻塞等待
• 對象鎖：synchronized修飾非靜態方法或者是對象的同步代碼塊，只對該對象生效，即同一時間只能有一個線程獲取該對象鎖，對象鎖和類鎖是不同的鎖，一個線程能夠同時得到對象鎖和類鎖
• wait：線程等待，釋放對象鎖，放棄cpu的控制權，等待被喚醒，yield是讓給優先級高的進行，wait等待，全部線程競爭資源 notify：喚醒一個正在等待的線程 notifyAll：喚醒全部等待的線程 以上3個方法可能是final的，不能被重寫，wait，notify與notifyAll都是配合着synchronized使用的，達到線程間的互斥訪問
• 線程通訊的常見方式： 1.共享內存 2.socket通訊 3.信號量 4.消息隊列：piedInputstream和pipedOutputStream
• 線程與進程的區別：一個程序就是一個進程，進程能夠包含多個線程，線程是程序種一個最小單元
• happens-before規則：若是兩個操做時happed-before的關係，則前一個操做對後一個操做可見
• CAS無鎖算法：樂觀鎖技術，有3個值，內存知V，預期值A，修改值B，若A=V，則修改，不然什麼都不會作

Redis

• redis常見的數據庫結構: 1.key-value 2.List 3.Hash 4.Set 5.Sort-Set
• redis常見的持久化機制: RDB，默認開啓，每5分鐘生成一次快照，同時也能夠觸發生成，save和bgsave命令 AOF，默認不開啓，每秒鐘附加命令到備份文件，備份數據最高的一種持久化方式
• redis與memcache比較:
  • 一、Redis和Memcache都是將數據存放在內存中，都是內存數據庫。不過memcache還可用於緩存其餘東西，例如圖片、視頻等等；
  • 二、Redis不只僅支持簡單的k/v類型的數據，同時還提供list，set，hash等數據結構的存儲；
  • 三、虛擬內存–Redis當物理內存用完時，能夠將一些好久沒用到的value 交換到磁盤；
  • 四、過時策略–memcache在set時就指定，例如set key1 0 0 8,即永不過時。Redis能夠經過例如expire 設定，例如expire name 10；
  • 五、分佈式–設定memcache集羣，利用magent作一主多從;redis能夠作一主多從。均可以一主一從；
  • 六、存儲數據安全–memcache掛掉後，數據沒了；redis能夠按期保存到磁盤（持久化）；
  • 七、災難恢復–memcache掛掉後，數據不可恢復; redis數據丟失後能夠經過aof恢復；
  • 八、Redis支持數據的備份，即master-slave模式的數據備份；
  • 九、應用場景不同：Redis出來做爲NoSQL數據庫使用外，還能用作消息隊列、數據堆棧和數據緩存等；Memcached適合於緩存SQL語句、數據集、用戶臨時性數據、延遲查詢數據和session等。
• redis實現分佈式鎖:
  • 1.互斥性，同一時間只有一個客戶端獲取到鎖
  • 2.不會發生死鎖，若是一個客戶端獲取到鎖後奔潰了，下一個客戶端能正常獲取鎖
  • 3.釋放性，誰得到鎖就誰來解鎖
  • 4.容錯性，只要redis大部分節點正常，客戶端就能正常的獲取鎖和解鎖 關鍵代碼：String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
• redis單機性能:redis讀取性能最高在7w/s以上

MySQL

常見的MySQL引擎類型

• InnoDB:支持提交，回滾，崩潰恢復等事務安全，行鎖，外鍵，能緩存索引，也能緩存數據， 使用場景：須要提供提交，回滾，奔潰恢復等事務安全能力，提供併發控制

• MyISAM:不支持事務，表級鎖定，讀取和寫入互相阻塞，索引緩存， 使用場景：若是隻是提供數據的插入和查詢，而且數據以讀爲主，併發少，MyISAM是很好的選擇

• Memory:存在內存中，查詢速度快， 使用場景：若是存儲一些臨時數據，數據量不大，該引擎會是最好的選擇，如一些臨時的數據

• Archive:不支持事務，不支持索引，只支持SELECT和INSERT操做 使用場景：若是表操做只有SELECT和INSERT，該引擎是最好的選擇，Archive支持高併發的插入操做，但不是事務安全的，該引擎常常用來存儲歸檔信息，如一些日誌記錄信息

• SQL語句執行慢如何排查解決 1.用explain分析SQL語句 2.是否能單表查詢，若不能，如果多表鏈接查詢，看鏈接類型，最好到最差const、eq_reg、ref、range、indexhe和ALL 3.通常在where，group by語句後面使用索引字段

• 常見的SQL優化手段 1）不使用子查詢 2）避免函數索引 3）用IN來替換OR 4）like雙%號沒法使用到索引 5）讀取適當的記錄LIMIT N,M 6）避免數據類型不一致 7）分組統計能夠禁止排序 8）禁止隨機取數據 9）避免沒必要要的ORDER BY 10）批量INSERT插入

• 索引做用

  • 優勢： 1）經過建立惟一性索引，能夠保證數據庫表中每一行數據的惟一性。 2）能夠大大加快 數據的檢索速度，這也是建立索引的最主要的緣由。 3）能夠加速表和表之間的鏈接，特別是在實現數據的參考完整性方面特別有意義。 4）在使用分組和排序 子句進行數據檢索時，一樣能夠顯著減小查詢中分組和排序的時間。 5）經過使用索引，能夠在查詢的過程當中，使用優化隱藏器，提升系統的性能。

• 缺點： 1）建立索引和維護索引要耗費時間，這種時間隨着數據量的增長而增長。 2）索引須要佔物理空間，除了數據表佔數據空間以外，每個索引還要佔必定的物理空間，若是要創建聚簇索引，那麼須要的空間就會更大。 3）當對錶中的數據進行增長、刪除和修改的時候，索引也要動態的維護，這樣就下降了數據的維護速度。

• 建立索引：索引的建立能夠在 CREATE TABLE 語句中進行，也能夠單獨用 CREATE INDEX 或 ALTER TABLE 來給表增長索引

• 數據結構：B-樹和B+樹，經過該數據結構快速的達到快速的查找的目的

Kafka

基本介紹：Kafka是一個分佈式的消息緩存系統，穩定性高，吞吐量高，適合併發量高的開發項目 優勢： 1.分佈式 2.實時 3.高吞吐量 4.消息持久化 應用場景： 1.異步處理：如用戶註冊系統，發送短信，發送郵件與註冊系統分開 2.應用解耦的，如訂單系統與庫存系統 3.流量削鋒，如秒殺活動 4.日誌系統，如大量日誌的採集與落地 5.聊天室系統

Elasticsearch

• 基本介紹：是一個實時的分佈式搜索引擎 優勢： 1）分佈式 2）高性能 3）實時搜索大量數據，搜索速度快
• 應用場景：大數據檢索應用，如棧內搜索，大數據全文檢索等系統

ZooKeeper

• 基本介紹：是一個分佈式的協調服務，如提供主從協調，配置管理，分佈式共享鎖，服務器節點動態上下線，統一的命名服務
• 優勢： 1）分佈式 2）高性能
• 基本原理：Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫作Zab協議
• 應用場景： 1）消息的發佈與訂閱 2）統一的命名服務 3）心跳檢測 4）配置管理

Mybatis

• 基本介紹：Mybatis是支持SQL查詢，存儲過程和高度映射的優秀持久化層框架，它消除了幾乎全部的JDBC代碼基本實現原理：mybatis底層仍是採用原生jdbc來對數據庫進行操做的，只是經過 SqlSessionFactory，SqlSessionExecutor,StatementHandler，ParameterHandler,ResultHandler和TypeHandler等幾個處理器封裝了這些過程
• 使用場景：主要應用在一些需求較多的項目，互聯網項目，敏捷開發

Dubbo

• 基本介紹：Dubbo 是阿里巴巴開源項目的一個分佈式服務框架。其致力於提供高性能和透明化的 RPC 遠程調用方案，以及 SOA 服務治理方案。
• 基本原理:使用ZooKeeper的主從協調與訂閱/發佈的服務，利用RMI遠程方法調用實現分佈式的微服務框架
• 使用場景: 1）商城作活動流量暴漲：防止系統崩掉 能夠經過dubbo來控制訪問量 2）分佈式服務器rpc過程調用壓力分擔

計算機網絡

• 爲何是4次揮手而不是3次？ 由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。 其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手