階段總結 - 一些不得不知道的Java知識點

JVM

　　JVM優化？

　　JVM內存模型？全部jdk版本的模型都同樣嗎？

　　對JVM的瞭解？

　　　　JVM內存分配？

　　　　GC 是在何時？對什麼東西？作了什麼事情？

分佈式、集羣

　　作一個分佈式事務怎麼作？

　　實現分佈式鎖怎麼實現

　　redis如何保證熱點數據？

　　緩存

　　序列化

　　數據庫鎖

Mybatis

　　#{}和${}區別

　　數據庫事務

Spring Boot

　　springBoot自動配置原理

　　@RestController

　　Spring 關於iOC容器 特色

　　Spring MVC 流程圖

redis

　　如何手動持久化

　　Memcached、Redis、MongoDB 對比

　　redis遍歷全部key的兩個命令 keys scan

　　　　keys

　　　　scan

mysql

　　索引分類

　　索引類型

　　建索引原則：

頁面訪問慢怎麼排查

　　慢查詢sql優化基本步

HashMap 和 HashTable區別？

ArrayList 與LinkedList 區別

說說知道的設計模式？

多線程狀態？

volatile 關鍵字

NIO 與 BIO 區別？那個更快。

HTTP協議

　　經常使用HTTP方法有哪些

　　GET與POST區別

　　HTTP請求報文與相應報文格式

　　HTTP請求

　　常見HTTP狀態碼

　　HTTP的缺點與HTTPS

　　HTTP優化

　　GET 下URL地址最大長度

搜索引擎

HQL

 

JVM

JVM優化？

查看堆空間大小分配（年輕代、年老代、持久代分配）

垃圾回收監控（長時間監控回收狀況）

線程信息監控：系統線程數量

線程狀態監控：各個線程都處在什麼樣的狀態下

線程詳細信息：查看線程內部運行狀況，死鎖檢查

CPU熱點：檢查系統哪些方法佔用了大量CPU時間

內存熱點：檢查哪些對象在系統中數量最大

 

堆設置

回收器選擇 （jdk 5前使用串行收集器，以後根據系統配置智能判斷。）

收集器有三種：串行、並行、併發收集器

串行收集器適用於 小數據量 的狀況

並行收集器適用於 吞吐量 優先的狀況

併發收集器適用於 響應時間 優先的狀況

 

JVM優化原則：

儘可能減小 youngGC 、儘可能減小 fullGC、縮短大對象生命週期，替換收集器、

 

JVM內存模型？全部jdk版本的模型都同樣嗎？

內存模型：java虛擬機棧、本地方法棧、程序計數器、堆、方法區

（線程共享：方法區、堆； 線程獨享：java虛擬機棧、本地方法棧、PC寄存器）

jdk 1.7 有永久代的概念。

jdk 1.8 取消永久代，添加了元空間。

元空間的本質和永久代相似，都是JVM規範中方法區的實現。不過元空間與永久代之間最大區別在於：元空間並不在虛擬機中，而是使用本地內存。默認狀況下，元空間的大小僅受本地內存限制。

 

對JVM的瞭解？

JVM內存分配？

Java虛擬機棧、本地方法棧、堆、方法區、程序計數器。

程序計數器：當前線程所執行的字節碼的行號指示器（線程私有區域，惟一沒有任何OOME狀況的區域）

java虛擬機棧：java方法執行的內存模型（線程私有，生命週期與線程相同。）

本地方法棧：線程建立時產生，方法執行時生成棧幀（爲Native方法服務）

方法區（持久代）：存儲類信息、靜態變量、常量等。區域用完，會拋出OutOfMemoryError。

堆：java代碼中全部new操做

 

 

 

GC 是在何時？對什麼東西？作了什麼事情？

時間：

Eden（新生代） 滿了，觸發 minor gc （新生代GC | 會致使全世界暫停，中止應用程序的線程，過程很短暫），

升到老年代的對象大於老年代剩餘空間，觸發 full gc，或者小於時 被 HandlePromotionFailure（HandlePromotionFailure 參數配置是否容許擔保失敗，若是容許，進行minor gc，不容許，進行 full gc） 參數強制 full gc；

gc 與 非gc 時間耗時超過了 GCTimeRatio（設置吞吐量大小） 的限制引起OOM（OutOfMemory）

調優 -- 經過NewRatio控制新生代老年代比例，經過MaxTenuringThreshold 控制進入老年前生存次數等。

對什麼東西：

從gc root（垃圾回收的根）搜索不到，並且通過第一次標記、清理後、仍然沒有復活的對象。

作了什麼事情：

新生代是複製清理，

新生代區有 Survivor Space 倖存者區，包含 To Survivor、 Form Survivor，兩個區域空間同樣大，垃圾回收時把不能回收的對象都放到 To Survivor中，結束後把To Survivor裏的內容都放到 Form Survivor內。

老年代是標記清理，標記清理後須要作整理，也有直接的標記整理算法。

複製清理須要較大內存，標記清理收集後有大量空間碎片。

 

分佈式理論：CAP定理、BASE理論

CAP - 一致性C、可用性A、分區容錯性P

BASE - 基本可用BA、軟狀態S、最終一致性E

 

分佈式、集羣

分佈式是個工做方式，集羣是個物理形態

 

·分佈式系統：

分佈式系統是若干獨立計算機的集合，這些計算機對於用戶來講就像是單個相關係統。

 

·分佈式系統核心本質

拆分 ：根據業務需求、成本限制。

鏈接 ：拆分後Process之間要能通訊

 

·爲何要使用分佈式

性能擴展 ： 系統高負載，單機沒法承受，經過使用多臺機器提升系統的負載能力

加強可靠性 ：爲了不故障，須要將業務分散開保留必定的冗餘

 

·集羣：

將相同的程序，經過不斷橫向擴展，以提升服務能力的方式。

 

作一個分佈式事務怎麼作？

1）兩階段提交（2PC）：

優勢：儘可能保證了數據的強一致，適用數據強一致性要求很高的領域

缺點：實現複雜，犧牲可用性，對象能影響大，不適合高併發性能場景。

 

2）補償事務（TCC）：針對每一個操做，都要註冊一個與其對應的確認和撤銷操做。

分三步 -- try階段，對業務系統作檢測及資源預留

Confim階段，對業務系統作確認提交。try階段成功，默認認爲confim階段也成功。

cancel階段，在業務執行錯誤，須要回滾狀態下，執行業務取消，預留資源釋放。

優勢：比2pc，實現流程簡單，數據一致性不如2pc

缺點：二、3步可能失敗，業務流程不太容易定義。

 

3）本地消息表（異步確保）

將分佈式事務拆分紅本地事務進行處理。

消息生產方，須要額外建一個消息表，並記錄消息發送狀態，消息表和業務數據在一個事務裏提交，而後消息會通過mq發送到消息的消費方，若是消息發送失敗，會進行重試發送。

消息消費方，須要處理這個消息，並完成本身的業務邏輯，若是本地事務處理成功，代表已經成功，若是處理失敗，會重試執行。若是業務失敗，會給生產方發送一個業務失敗消息，通知生產方回滾。

優勢：經典的實現，避免分佈式事務。實現最終一致性

缺點：消息表會耦合到業務中。

 

4）MQ事務消息

RocketMQ 支持，RabbitMQ和Kafka不支持

使用阿里中間件 RocketMQ中間件，第一步拿到消息地址，第二步 執行本地事務，第三部經過拿到的地址去訪問消息，並修改狀態。

優勢：實現了最終的一致性，不須要依賴本地數據庫事務

缺點：實現難度大，主流MQ不支持。

 

實現分佈式鎖怎麼實現

CAP理論最多實現兩項

三種方式：基於數據庫實現分佈式鎖、基於緩存實現分佈式鎖、基於zookeeper實現分佈式鎖

基於數據庫實現 -

建立一張鎖表，要鎖住否個方法或資源時，在表中增長一條記錄，釋放鎖時候刪除記錄。

優勢：直接用數據庫，容易理解，

缺點：有問題，解決麻煩，開銷大，性能低。

基於緩存實現 -

能夠提供更好的性能，redis的setnx方法，

優勢：性能好、實現方便

缺點：超時時間不必定靠譜。

基於zookeeper 實現分佈式鎖

基於zookeeper臨時有序節點實現分佈式鎖。 客戶端某個方法加鎖，在zookeeper上與該方法對應的指定節點的目錄下，生成一個惟一的瞬時有序節點。判斷有序節點中序號最小的一個判斷是否獲取鎖。釋放鎖時候刪除瞬時節點便可。能夠避免服務宕機致使的鎖沒法釋放產生的死鎖問題。

優勢：有效解決單點問題，不可重入問題，非租塞問題以及鎖沒法釋放的問題。實現簡單。

缺點：性能不如緩存實現的分佈式鎖。

 

redis如何保證熱點數據？

redis內存數據集大小上升到必定大小的時候，就會施行數據淘汰策略（回收策略）

volatile-lru：從已設置過時時間的數據集中挑選最近最少使用的數據淘汰

volatile-ttl：從已設置過時時間的數據集中挑選將要過時的數據淘汰

volatile-random：從已設置過時時間的數據集中任意選擇數據淘汰

allkeys-lru：從數據集中挑選最近最少使用的數據淘汰

allkeys-random：從數據集中任意選擇數據淘汰

no-enviction：禁止驅逐數據

 

緩存

工做原理：當CPU要讀取一個數據時，首先從CPU緩存中查找，找到就當即反饋處理。沒找到，就從速率相對較慢的內存中讀取並送給CPU處理。

 

序列化

把java對象轉化爲有序字節流的過程

做用：在傳遞和保存的時候，保證對象的完整性和可傳遞性。

優勢：實現數據持久化，能夠把數據永久的保存在硬盤上；實現遠程通訊；在進程間傳遞對象

要求：只有實現了 Serializable 或 Externalizable 接口的類的對象才能被序列化。

 

數據庫鎖

數據庫爲了保證數據的一致性，而使各類共享資源在併發訪問下變得有序的一種規則。

表級鎖 - 最大顆粒鎖機制，邏輯很是簡單，系統負面影響小，獲取鎖和釋放鎖速度很快。

兩種模式 - 表共享讀鎖、表獨佔寫鎖

操做前自動加鎖，用戶不須要干預。

優化 - 縮短鎖定時間、分離能並行的操做、合理利用讀寫優先級

行級鎖 - 鎖定對象顆粒度小，能給予程序最大的併發處理，獲取鎖釋放鎖須要事情多，消耗大，容易發送死鎖。

InnoDB存儲引擎實現的行級鎖 - 共享鎖、排它鎖，表級鎖 - 意向共享鎖、意向排它鎖。

頁級鎖 - 消耗和能力和粒度 都在表級所和行級鎖之間

 

 

Mybatis

#{}和${}區別

${}是 properties文件中的變量佔位符，用於標籤屬性值和sql內部，屬於靜態文本替換

#{}是 sql的參數佔位符，Mybatis會將sql的#{}替換爲？號，在sql執行前會根據傳遞的參數按序給佔位符設置參數值。

 

數據庫事務

一條或多條數據庫操做語句的組合，保證數據的一致性和完整性

事務併發會產生的問題

一、第一類丟失更新

二、髒讀

三、不可重複讀

四、第二類丟失更新

五、幻讀

事務隔離 serializable 事務被處理爲順序執行，解決全部問題。

 

Spring Boot

springBoot自動配置原理

main方法中，添加@SpringBootApplication 或者@EnableAutoConfiguration 會自動去maven中讀取每一個starter中的spring.factories文件，該文件裏配置了全部須要被建立spring容器中的bean。

 

@RestController

（

@Controller 處理HTTP請求，注：單獨使用會報錯，由於沒有使用模板，配合 @ResponseBody使用

@RestController 是 @ResponseBody 和 @Controller 的組合註解

@RequestMapping 配置 url 映射，能夠做用在控制器的某個方法上，也能夠用在此控制器類上

當控制器在類級別上添加@RequestMapping註解，註解會應用到控制器的全部處理器方法上；

處理器方法上的@RequestMapping 註解會對類級別上的@RequestMapping 聲明進行補充

例：

@RestController

@RequestMapping（「/hello」）

public class HelloController {

@RequestMapping( value="/sayHello", method = RequestMethod.GET)

public String sayHello(){

return "hello";

}

}

@ PathVaribale 獲取url中的數據

@ RequestParam 獲取請求參數的值

@GetMapping 組合註解

）

 

aop 面向切面編程

ioc 依賴注入

spring的ioc容器是spring的核心，spring aop 是spring 框架的重要組成部分

DI機制 依賴注入（Dependecy Injection） 和控制反轉 （Inversion of Control ）是同一個概念

在spring中建立調用者的工做再也不由路由器來完成，所以成爲控制反轉。建立被調用者的工做有spring來完成，而後注入調用者，所以也稱爲依賴注入。

 

Spring 關於iOC容器 特色

- 總的來講：IOC容器完成了 對象的建立 和 依賴的管理注入。

- 詳細點：

依賴對象不直接引用，而是引用接口

對象的建立與注入由Spring決定，Spring 能夠根據xml配置來建立對象

- IOC能力

依賴解耦，依賴對象只要知足接口就能自由替換

依賴封裝，Spring在注入對象時，可對對象執行操做

 

Spring MVC 流程圖

 

一、請求到達 SpringMVC 前段控制器的時候，會到達 DispatcherServlet 的 doService() 方法

二、接着調用 doDispatcher() 方法

三、接着調用 getHandler(processedRequest) 獲取當前的處理器；返回當前請求的處理器鏈。當前處理器鏈封裝了負責請求的處理器及其方法。

四、根據請求的處理器獲取處理器適配器，經過調用 getHandlerAdapter() 獲取

五、接下來調用 handler() 方法處理請求，返回modelAndView對象

 

redis

如何手動持久化

save 同步保存操做，將當前redis實例的全部數據快照（snapshot）以RDB文件的形式保存到硬盤。保存成功時返回ok。

bgsave 命令執行後當即返回ok，而後redis fork（分叉）出一個新子進程，原來的redis進程（父進程）繼續處理客戶端請求，子進程負責將數據保存到磁盤，而後退出。

結論：save 保存阻塞主進程，客戶端沒法鏈接redis，等save完成後，主進程纔開始工做，客戶端能夠鏈接。

bgsave 分叉子進程，執行save過程，不影響主進程，客戶端能夠正常鏈接redis，子進程fork執行save完成後，通知主進程，子進程關閉。

 

Memcached、Redis、MongoDB 對比

redis 是一個開源，內存存儲的數據結構服務器，可用做數據庫，高速緩存和消息隊列。

Memcached 是一個自由開源的，高性能，分佈式內存對象緩存系統。

MongoDB 是一個基於分佈式文件存儲的數據庫，文檔型的非關係型數據庫。

- 性能上

redis只使用單核，Memcached 可使用多核，平均每一核上，小數據存儲 redis性能大於memcached，大於100K以上的數據Memcached性能更高。二者性能都大於mongoDB

- 操做上

memcached 數據結構單一，僅用來緩存數據，而redis支持更加豐富的數據類型，能夠在服務端直接對數據進行豐富操做，能夠減小IO次數和數據體積。

MongoDB 支持豐富的數據表達，索引，相似關係型數據庫，支持查詢語言豐富。

- 可靠性上

Memcached 不支持數據持久化，斷電或重啓後數據消失，穩定性好。

redis支持數據持久化和數據恢復，容許單點故障，同時會付出性能代價。

MongoDB從1.8版開始採用binlog方式支持持久化的可靠性。

-應用場景上

Memcached 動態系統中減輕數據庫負載，提高性能；作緩存，適合多讀少寫，大數據量的狀況（如人人網大量查用戶信息、好友信息）

redis 適用對讀寫效率要求都很高，數據處理業務複雜和對安全性要求較高的系統

mongoDB 解決海量數據的訪問效率問題

注：- Memcached 單個key-value大小有限，一個value最大支持1MB； redis key最大512M，value 1GB

- Memcached 是內存緩存，對可靠性無要求； redis 對可靠性要求較高

- 本質上 memcached 是單一key-value 內存cache； redis 是一個數據結構內存數據庫，支持五種數據類型，不只能夠緩存，還可處理簡單邏輯運算，redis不只能夠緩存，還能夠做爲數據庫用

- MongoDB不支持事務

 

redis遍歷全部key的兩個命令 keys scan

redis 關於各類類型的運用， 模糊遍歷，取list值

keys速度快，在一百萬個key的數據庫中執行一次查詢須要40毫秒，在大數據中查找特定keys，最好用redis的集合結構sets。keys命令返回匹配的key。

2.8以上版本 scan 命令，scan每次執行都會返回少許元素，不會阻塞服務器。

scan是一個基於遊標的迭代器，命令每次被調用都須要使用上一次這個調用返回的遊標做爲該次調用的遊標參數，以延續以前的迭代過程，當scan命令的油表參數（cursor）被設置爲0時，服務器將開始一次新的迭代。當服務器向用戶返回值爲0的遊標時，表示迭代器已結束。

 

scan

scan 0 從0遊標開始查詢key

scan 0 count 5 scan命令，從0遊標開始，查詢5條數據。不能嚴格控制返回的key數量，只是一個大體約束。

scan 0 match *11* 相似於 keys scan從0命令開始，查詢 key包含11的值。

 

mysql

索引，原理，做用

（索引本質：經過不斷縮小想要獲取數據的範圍來篩選出最終想要的結果，同時把隨機事件變成順序事件。有了索引機制，能夠老是用同一種查找方式來鎖定數據

索引分類

普通索引 index：加速查找

惟一索引 主鍵索引，primary key，加速查找+約束（不爲空且惟一），惟一索引：unique，加速查找+約束

聯合索引 -primary key（id，name）聯合主鍵索引； -unique（id，name） 聯合惟一索引； -index（id，name）聯合普通索引 【查詢時使用聯合索引的一個字段，這個字段在索引中全部字段的第一個，就會用到索引。】

全文索引 fulltext：用於搜索很長一篇文章的時候，效果最好。

 

【彙集索引：給表加上主鍵，整個表就變成一個索引（彙集索引），主鍵的做用就是把 [表] 的數據格式轉換成[索引（平衡樹）]的格式放置。

索引讓數據庫查詢速度上升，使寫入數據的速度降低。緣由是平衡樹這個結構必須維持在一個正確的狀態，增刪改數據會改變平衡樹各個節點的索引數據，破壞樹結構，所以數據改變時，DBMS必須從新梳理索引樹結構確保正確。這回帶來不小的性能開銷。

 

非彙集索引：每次給字段建一個新索引，字段中數據就會被複制一份出來，用於生成索引。給表添加索引，會增長表的體積，佔用磁盤空間。

（非彙集索引和彙集索引的區別在於，經過彙集索引能夠查到須要查詢的數據，經過非彙集索引能夠查到記錄對應的主鍵值，再使用主鍵的值經過彙集索引查找到須要的數據。）

 

覆蓋索引（複合索引、多字段索引）：

 

 

】

索引類型

hash 類型 ：查詢單條快，範圍查詢慢

btree 類型 ：平衡樹（B+樹），層數越多，數據量指數級增加（innodb默認支持）

 

建索引原則：

一、最左前綴原則。mysql 會一直向右匹配，直到遇到範圍查詢（>、<、between、like）就中止

二、= 和 in 索引查詢部分前後。

三、儘可能選擇區分度高的列做爲索引，字段不重複的比例越大，掃描記錄數越少。

四、索引列不能參與計算

五、儘可能擴展索引，不要新建索引。有索引a，要加索引（a，b）,只要修改原來的索引便可

 

mysql版本 5.1 select version() 能夠獲得

postgresql 9.4 select version() 能夠獲得

 

頁面訪問慢怎麼排查

ping端口是否能接通

是否有線程阻塞

是否形成數據庫鎖表

 

慢查詢sql優化基本步

一、運行查看sql是否真的很慢

二、where條件單表查，鎖定最小返回記錄表。

三、explain 查看執行計劃，

四、order by limit 形式的sql語句讓排序表優先查

五、瞭解業務方使用場景

六、加索引時參照建索引的幾大原則

七、觀察結果，不符合預期從頭開始

 

mysql的慢查詢日誌

mysql日誌包括 錯誤日誌、二進制日誌、通用查詢日誌、慢查詢日誌等

通用查詢日誌：記錄創建的客戶端連接和執行的語句

慢查詢日誌：記錄全部執行時間超過long_query_time 秒的全部查詢或者不使用索引的查詢，默認不開啓，默認值10秒，

 

 

HashMap 和 HashTable區別？

1）對 null key 和 null value 支持不一樣。

HashTable 不支持 null key和null value。

HashMap 能夠有一個 null key，多個 null value。不能用get() 方法判斷HashMap中是否存在某個鍵，應該用 containsKey() 方法來判斷。

2）線程安全性不一樣

HashTable 是線程安全的，它的每一個方法都加入了synchronized 方法。

HashMap 是線程不安全的，多併發可能產生死鎖等問題。

HashMap 效率比HashTable 好不少。ConcurrentHashMap 是線程安全的。且效率比Hashtable高。由於ConcurrentHashMap 使用了分段鎖。並不對整個數據進行鎖定。

3）初始容量大小和每次擴容量大小不一樣

Hashtable 默認大小爲 11，每次擴充容量變爲原來的 2n+1.

HashMap 默認大小爲 16，每次擴充，容量變爲原來的2倍。

 

ArrayList 與LinkedList 區別

public class ArrayList<E> extends AbstractList<E> implements List<E>, RandomAccess, ...

public class LinkedList<E> extends AbstractSequentialList<E> implements List<E>, Queue<E>, ...

ArrayList 實現了隨機訪問的接口 ； LinkedList 實現了Queue的接口；

ArrayList 是基於數據實現的list，有數組特性 ； LinkedList 是基於鏈表實現的list，有鏈表特性。

優缺點：

ArrayList 優勢：適合隨機讀取時候，讀取速度快，能夠一步get(index)

缺點：添加值很慢，

LinkedList 優勢：添加值很快，實現棧和隊列方面 LinkedList 優於 ArrayList

ArrayList 增刪比 LinkedList 開銷更大，除了有查找時間複雜度，還有移動過程。

 

說說知道的設計模式？

大體分三類：建立型模式、結構型模式、行爲型模式

建立型模式：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式

結構型模式：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、亨元模式

行爲型模式：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。

 

例：

工廠模式 - 建立一個工廠接口和多個工廠實現類，須要增長新功能時候增長實現類，不用修改以前的代碼。

單例模式 - JVM中，單例對象只有一個實例存在。

代理模式 - 用代理類調用原來的方法，對產生的結果進行控制。

適配器模式 （例：向外提供一個接口，後端後不一樣的各類實現。經過調用的數據，去對應實現方法。）

 

設計模式六大原則：總原則 開閉原則（對擴展開放、對修改關閉）

單一職責原則

里氏替換原則

依賴倒轉原則

接口隔離原則

迪米特法則（最少直到原則）

合成複用原則

 

多線程狀態？

線程包括5種狀態 - 新建、就緒、運行、阻塞、死亡

新建狀態(new)：線程被建立後進入新建狀態。 Thread thread = new Thread();

就緒狀態(Runable)：可執行狀態，其餘線程調用該對象的start()方法，進入就緒狀態。 thread.start().

運行狀態(Running)：線程獲取CPU權限進行執行。

阻塞狀態(Blocked)：線程由於某種緣由放棄CPU使用權，暫時中止運行。分三種阻塞

等待阻塞 - 經過調用線程的 wait() 方法，讓線程等待某工做的完成。

同步阻塞 - 線程在獲取 synchronized 同步鎖失敗 (鎖被其餘線程佔用)，它會進入同步阻塞狀態

其餘阻塞 - 經過調用線程的sleep() 或 join() 或發出了I/O請求時，線程會進入阻塞狀態。當sleep()狀態超時，join() 等待線程終止或者超時，或者I/O處理完畢時，線程從新轉入就緒狀態。

死亡狀態(Dead)：線程執行完成或因異常退出run()方法，該線程結束生命週期。

 

wait() 與 Sleep() 、Join() 的比較

wait() 會釋放對象的同步鎖，sleep() 則不會釋放鎖。join() 底層實現時wait()，做用是等待線程對象被銷燬。

 

volatile 關鍵字

- 共享變量（類的成員變量、靜態變量）被volatile修飾後，有兩層語義 ：

1）保證了不一樣線程對這個變量進行操做時的可見性，即一個線程修改了某個變量的值，新值對其餘線程來講是當即可見的（強制修改的值當即寫入主存）。

2）禁止進行指令重排序

- 不能保證原子性，須要synchronized鎖輔助。

- 能夠保證有序性

加入volatile關鍵字，會多出一個lock前綴指令。至關於一個內存屏障，提供三個功能 ：

1）執行到內存屏障這句指令時，它前面的操做已經所有完成。

2）強制將對緩存的修改操做當即寫入主存。

3）寫操做會致使其餘CPU中對應的緩存行無效。

 

 

NIO 與 BIO 區別？那個更快。

NIO 非租塞IO ：多線程對某資源進行IO操做時會把資源先操做至內存緩衝區，而後詢問是否IO操做就緒，是則進行IO操做。不然進行下一步操做。而後不斷輪詢是否IO操做就緒，直到IO操做就緒後進行相關操做。操做更快。

BIO 阻塞IO ：多線程對某資源進行IO操做時會出現阻塞，一個線程進行IO操做完才通知另外的IO操做線程。必須等待。

 

HTTP協議

HTTP請求由三部分組成，請求行、消息報頭、請求正文

HTTP（超文本傳輸協議）是一個基於請求與相應模式的、無狀態的應用層的協議。

 

經常使用HTTP方法有哪些

GET：用於請求訪問已經被URL識別的資源，能夠經過URL傳參給服務器。

POST：傳輸信息給服務器。

PUT：傳輸文件，報文主題中包含文件內容，保存到對應URL位置。

HEAD：得到報文首部，與get相似，不返回報文主體，用於驗證URL是否有效。

DELETE：刪除文件，刪除對應URL位置的文件

OPTIONS：查詢相應URL支持的HTTP方法。

 

GET與POST區別

一、get重點在從服務器上獲取資源；post重點在向服務器發送數據

二、get傳輸時經過url請求，？+&傳輸多個值，過程可見；post傳輸經過http的post機制，將字段與對應值封存在請求實體中發送給服務器。過程對用戶不可見。

三、get傳輸數據量小，效率高；post能夠傳輸大量數據

四、get不安全，url可見，密碼可見；post安全性高

五、get只支持ASCII字符，向服務器傳的中文字符可能會亂碼；post支持標準字符集，能夠正確傳遞中文字符。

 

HTTP請求報文與相應報文格式

請求報文包含：請求行（請求方法，url，HTTP版本信息），請求頭，請求體

相應報文包含：狀態行（包含HTTP版本，狀態碼，狀態碼的緣由短語），響應頭，相應體

 

HTTP請求 ： 指從客戶端到服務端的請求消息。包括 消息首行中，對資源的請求方法，資源的標識符及使用協議。

組成 ： 三部分 - 一、請求方法url協議/版本； 二、請求頭； 三、請求正文

 

常見HTTP狀態碼

1**：指示信息 -- 表示請求已接收，繼續處理

2**：成功 -- 請求已成功接收

3**：重定向 -- 要完成請求必須進行更進一步的操做

4**：客戶端錯誤 -- 語法錯誤或請求沒法實現

5**：服務端錯誤 -- 服務器未能實現合法請求

 

HTTP的缺點與HTTPS

缺點：通訊使用明文不加密，內容可能被竊聽；不驗證通訊方身份，可能遭到假裝；沒法驗證報文完整性，可能被篡改

HTTPS是HTTP加上加密處理+認證+完整性保護

 

HTTP優化

利用負載均衡優化和加速HTTP應用

利用HTTP Cache來優化網站

 

GET 下URL地址最大長度

之前256，如今不止了

在IE8 下，4076，超事後自動忽略後面的內容。

在firefix下，7530，超事後報錯。

在Chrome下，7675，超事後報錯。

 

搜索引擎

原理概述：引擎後臺，有一些用於搜索網頁信息的程序，所收集的信息是能代表網站內容的關鍵詞或短語，接着將這些信息的索引放到數據庫中。

原理：爬行和抓取（引擎排出一個能在網上發現新網頁並抓文件的程序：蜘蛛。從已知網站出發，訪問網頁並抓取文件，經過爬蟲去爬互聯網上的外鏈，跟蹤網頁連接，訪問更多網頁，這個過程叫爬行。反向連接是搜索引擎優化的最基本因素之一，搜索引擎抓取的頁面文件與瀏覽器獲得的徹底一致，抓取的文件存入數據庫）

創建索引（蜘蛛抓取的頁面文件分解、分析後，以巨大表格形式存入數據庫，過程叫索引）

搜索詞處理（如中文的分詞處理，去除中止詞，判斷是否須要啓動整合搜索，判斷是否有拼寫錯誤或錯別字）

排序（）

數據結構：引擎核心數據結構爲倒排文件（倒排索引）

全文搜索引擎

目錄索引

元索引

 

HQL

面向對象的查詢語言

步驟：

一、獲取Hibernate Session對象、

二、編寫HQL語句、

三、以HQL語句做爲參數，調用Session的CreateQuery方法建立查詢對象、

四、若是HQL包含參數，調用Query的setXxx方法爲參數賦值。

五、調用Query對象的list() 或 uniqueResult() 方法返回查詢結果列表