面試題(校招java)

時間 2019-11-15

標籤面試 java 欄目快樂工作简体版

原文原文鏈接

1：linux線程和進程的區別？javascript

進程是程序執行時的一個實例，即它是程序已經執行到課中程度的數據結構的聚集。從內核的觀點看，進程的目的就是擔當分配系統資源（CPU時間、內存等）的基本單位。html

線程是進程的一個執行流，是CPU調度和分派的基本單位，它是比進程更小的能獨立運行的基本單位。一個進程由幾個線程組成（擁有不少相對獨立的執行流的用戶程序共享應用程序的大部分數據結構），線程與同屬一個進程的其餘的線程共享進程所擁有的所有資源。java

進程是資源分配的最小單位，線程是CPU調度的最小單位node

使用多線程的理由之一是和進程相比，它是一種很是"節儉"的多任務操做方式。咱們知道，在Linux系統下，啓動一個新的進程必須分配給它獨立的地址空間，創建衆多的數據表來維護它的代碼段、堆棧段和數據段，這是一種"昂貴"的多任務工做方式。而運行於一個進程中的多個線程，它們彼此之間使用相同的地址空間，共享大部分數據，啓動一個線程所花費的空間遠遠小於啓動一個進程所花費的空間，並且，線程間彼此切換所需的時間也遠遠小於進程間切換所須要的時間。據統計，總的說來，一個進程的開銷大約是一個線程開銷的30倍左右，固然，在具體的系統上，這個數據可能會有較大的區別。mysql

使用多線程的理由之二是線程間方便的通訊機制。對不一樣進程來講，它們具備獨立的數據空間，要進行數據的傳遞只能經過通訊的方式進行，這種方式不只費時，並且很不方便。線程則否則，因爲同一進程下的線程之間共享數據空間，因此一個線程的數據能夠直接爲其它線程所用，這不只快捷，並且方便。固然，數據的共享也帶來其餘一些問題，有的變量不能同時被兩個線程所修改，有的子程序中聲明爲static的數據更有可能給多線程程序帶來災難性的打擊，這些正是編寫多線程程序時最須要注意的地方linux

2：一致性hash算法正則表達式

問題引入：爲何須要一致性hash？算法

在分佈式系統中，若是某業務能夠由多個相同的節點處理，很容易想到用HASH的方式將業務請求分散到這些節點處理，若是有N個節點，計算方法爲：HASH（id）% N。spring

若是隻是簡單的計算，不涉及用戶狀態，這是一個簡單有效的方案。若是節點的計算涉及用戶狀態，好比維護購物車、Memcache緩存服務等，好像也沒什麼問題，只要用同一個數據作id，上述HASH的結果也保持不變。但若是節點數量發生變化，好比因爲業務量的增大而增長節點或因爲機器宕機而減小節點，上述HASH的結果就不同了。若增長2個節點，某id原處理節點爲HASH（id）% N，新的處理節點就變成了HASH（id）% （N + 2），可能會將大量id的處理節點打亂從新分配，就會發現以前某節點保存的用戶數據用不到了，而新的處理節點根本沒有這些數據。在這段時間內，這些用戶的狀態受到破壞，若是是購物車，車裏的東西都沒了，若是是緩存服務，以前的緩存都消失了，起不到緩存的效果。可能須要用戶從新登陸，可能須要從數據庫更新緩存，可能由此引入新的問題。sql

一致性哈希在必定程度上緩解了這個問題步驟爲：

1.將整個哈希值空間組織成一個虛擬圓環，假設某哈希函數H的值空間爲0-(2^32-1)，即32位無符號整數

2.將各節點用H函數哈希，能夠將服務器的IP或主機名做爲關鍵字哈希，這樣每一個節點就能肯定其在哈希環上的位置

3.將id用H函數映射到哈希空間的一個值，沿該值向後，將遇到的第一個節點作爲處理節點

下圖中，若某id的HASH值落在node1和node2各自HASH值的中間位置，則此id對應的業務請求由node2處理。

當增長服務節點時，只會影響與之相鄰的某一節點，其餘節點不受影響。若是在node2和node4之間增長一個node5，則只有node4處理的部分 id（HASH值落在node2以後、node5以前的那部分id）變爲由node5來處理，其餘節點處理的id不變。比開頭所述的簡單HASH方式有了很大的改善。

若是節點數很少，將這些節點映射到值空間以後，分佈可能會很不均勻，必然會形成個別節點處理的id數量遠大於其餘節點，這就起不到負載均衡的效果。這能夠經過引入虛擬節點的方式解決，即對每個節點計算多個HASH值，儘可能保證這些HASH值比較均勻的分佈在值空間中。當根據id查找節點時，找到的是虛擬節點，而後再根據虛擬節點查找對應的真實節點。多了一次查找的過程。

3：TCP和UDP的區別？

TCP協議的三次握手四次揮手

位碼即tcp標誌位,有6種標示:SYN(synchronous創建聯機)、 ACK(acknowledgement 確認) 、PSH(push傳送) FIN(finish結束)、 RST(reset重置) 、 URG(urgent緊急) 、Sequence number(順序號碼)、 Acknowledge number(確認號碼)

第一次握手：主機A發送位碼爲syn＝1,隨機產生seq number=1234567的數據包到服務器，主機B由SYN=1知道，A要求創建聯機；

第二次握手：主機B收到請求後要確認聯機信息，向A發送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=7654321的包

第三次握手：主機A收到後檢查ack number是否正確，即第一次發送的seq number+1,以及位碼ack是否爲1，若正確，主機A會再發送ack number=(主機B的seq+1),ack=1，主機B收到後確認seq值與ack=1則鏈接創建成功。

完成三次握手，主機A與主機B開始傳送數據

1) 基於鏈接與無鏈接；
2) 對系統資源的要求（TCP較多，UDP少）；
3) UDP程序結構較簡單；
4) 流模式與數據報模式；
5) TCP保證數據正確性，UDP可能丟包，TCP保證數據順序，UDP不保證。

說明狀況下使用TCP和UDP呢?

在注重速度的時候使用UDP---》如：視頻聊天時，語音聊天
在注重安全的時候使用TCP---》如：下載文件時

4：linux進程通訊

進程通訊有以下一些目的：
A、數據傳輸：一個進程須要將它的數據發送給另外一個進程，發送的數據量在一個字節到幾M字節之間
B、共享數據：多個進程想要操做共享數據，一個進程對共享數據的修改，別的進程應該馬上看到。
C、通知事件：一個進程須要向另外一個或一組進程發送消息，通知它（它們）發生了某種事件（如進程終止時要通知父進程）。
D、資源共享：多個進程之間共享一樣的資源。爲了做到這一點，須要內核提供鎖和同步機制。
E、進程控制：有些進程但願徹底控制另外一個進程的執行（如Debug進程），此時控制進程但願可以攔截另外一個進程的全部陷入和異常，並可以及時知道它的狀態改變。

如今linux使用的進程間通訊方式：
（1）管道（pipe）和有名管道（FIFO）
（2）信號（signal）
（3）消息隊列
（4）共享內存
（5）信號量
（6）套接字（socket)

5：如何實現手機通信錄的查找時候的提示功能？

功能：輸入拼音、電話號碼、中文姓名、姓名首字母縮寫查詢

6：B+樹？

B+樹是根據多路查找樹 ---> B樹的延伸出來的樹的數據結構，是爲了方便遍歷而來的，由於全部的關鍵字都在葉子節點上，且是有一個鏈表來維持順序的。

7：mysql引擎

存儲引擎是什麼？

MySQL中的數據用各類不一樣的技術存儲在文件(或者內存)中。這些技術中的每一種技術都使用不一樣的存儲機制、索引技巧、鎖定水平而且最終提供普遍的不一樣的功能和能力。

經過選擇不一樣的技術，你可以得到額外的速度或者功能，從而改善你的應用的總體功能。

例如，若是你在研究大量的臨時數據，你也許須要使用內存存儲引擎。內存存儲引擎可以在內存中存儲全部的表格數據。又或者，你也許須要一個支持事務處理的數據庫(以確保事務處理不成功時數據的回退能力)。

這些不一樣的技術以及配套的相關功能在MySQL中被稱做存儲引擎(也稱做表類型)。MySQL默認配置了許多不一樣的存儲引擎，能夠預先設置或者在 MySQL服務器中啓用。你能夠選擇適用於服務器、數據庫和表格的存儲引擎，以便在選擇如何存儲你的信息、如何檢索這些信息以及你須要你的數據結合什麼性能和功能的時候爲你提供最大的靈活性

8：TCP/IP知識，IP四元組

9：快排和堆排序的原理

10：java虛擬機

(1) jvm啓動流程

(2) jvm基本結構

(3) 內存模型

(4) 解釋運行和編譯運行

11：java類加載機制

類從被加載到虛擬機內存中開始，直到卸載出內存爲止，它的整個生命週期包括了： 加載、驗證、準備、解析、初始化、使用和卸載 這7個階段。其中， 驗證、準備和解析這三個部分統稱爲鏈接（linking）

12：ARP（地址解析協議），請用簡單語言說明其的工做原理

1. 首先，每臺主機都會在本身的ARP緩衝區 (ARP Cache)中創建一個 ARP列表，以表示IP地址和MAC地址的對應關係。

2. 當源主機須要將一個數據包要發送到目的主機時，會首先檢查本身 ARP列表中是否存在該 IP地址對應的MAC地址，
若是有﹐就直接將數據包發送到這個MAC地址；若是沒有，就向本地網段發起一個ARP請求的廣播包，查詢此目的主機對應的MAC地址。此ARP請求數據包裏包括源主機的IP地址、硬件地址、以及目的主機的IP地址。

　　3. 網絡中全部的主機收到這個ARP請求後，會檢查數據包中的目的IP是否和本身的IP地址一致。若是不相同就忽略此數據包；若是相同，該主機首先將發送端的MAC地址和IP地址添加到本身的ARP列表中，若是ARP表中已經存在該IP的信息，則將其覆蓋，而後給源主機發送一個 ARP響應數據包，告訴對方本身是它須要查找的MAC地址；

　　4. 源主機收到這個ARP響應數據包後，將獲得的目的主機的IP地址和MAC地址添加到本身的ARP列表中，並利用此信息開始數據的傳輸。若是源主機一直沒有收到ARP響應數據包，表示ARP查詢失敗。

13：OSI七層模型

應用層： 文件傳輸，電子郵件，文件服務，虛擬終端 TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet

表示層： 數據格式化，代碼轉換，數據加密沒有協議. (信息的語法語義以及它們的關聯、如加密解密、轉換翻譯、壓縮解壓縮)

會話層： 解除或創建與別的接點的聯繫沒有協議 (不一樣機器上的用戶之間創建及管理會話)

傳輸層： 提供端對端的接口 TCP，UDP (接受上一層的數據，在必要的時候把數據進行分割，並將這些數據交給網絡層，且保證這些數據段有效到達對端)

網絡層： 爲數據包選擇路由 IP，ICMP，RIP，OSPF，BGP，IGMP (控制子網的運行，如邏輯編址、分組傳輸、路由選擇)

數據鏈路層： 傳輸有地址的幀以及錯誤檢測功能 SLIP，CSLIP，PPP，ARP，RARP，MTU (物理尋址，同時將原始比特流轉變爲邏輯傳輸線路)

物理層： 以二進制數據形式在物理媒體上傳輸數據 ISO2110，IEEE802，IEEE802.2 (機械、電子定時接口通訊信道上的原始比特流傳輸 )

14：HTTP協議的使用過程

(1) 請求：客戶端向服務器索要數據

http協議規定:一個完整的http請求包含'請求行','請求頭','請求體'三個部分;

請求行：包含了請求方法,請求資源路徑,http協議版本. "GET /resources/images/ HTTP/1.1"

請求頭:包含了對客戶端的環境描述,客戶端請求的主機地址等信息.

Accept: text/html ( 客戶端所能接收的數據類型 )

Accept-Language: zh-cn ( 客戶端的語言環境 )

Accept-Encoding: gzip( 客戶端支持的數據壓縮格式 )

Host: m.baidu.com( 客戶端想訪問的服務器主機地址 )

User-Agent: Mozilla/5.0(Macintosh;Intel Mac OS X10.10 rv:37.0) Gecko/20100101Firefox/37.0( 客戶端的類型,客戶端的軟件環境 )

請求體:客戶端發給服務器的具體數據,好比文件/圖片等.

(2) 響應：服務器返回客戶端想要的數據

http協議規定:一個完整的http響應包含'狀態行','響應頭','實體內容'三個部分;

狀態行:包含了http協議版本,狀態嗎,狀態英文名稱."HTTP/1.1 200 OK"

響應頭:包含了對服務器的描述,對返回數據的描述.

Content-Encoding: gzip(服務器支持的數據壓縮格式) Content-Length: 1528(返回數據的長度)

Content-Type:application/xhtml+xml;charset=utf-8(返回數據的類型)

Date: Mon,15Jun201509:06:46GMT(響應的時間) Server: apache (服務器類型)

實體內容:服務器返回給客戶端的具體數據(圖片/html/文件...).

15：SQL注入

SQL Injection：就是經過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。

具體來講，它是利用現有應用程序，將（惡意）的SQL命令注入到後臺數據庫引擎執行的能力，它能夠經過在Web表單中輸入（惡意）SQL語句獲得一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。

如何防止SQL Injection：

1.永遠不要信任用戶的輸入，要對用戶的輸入進行校驗，能夠經過正則表達式，或限制長度，對單引號和雙"-"進行轉換等。

2.永遠不要使用動態拼裝SQL，可使用參數化的SQL或者直接使用存儲過程進行數據查詢存取。

3.永遠不要使用管理員權限的數據庫鏈接，爲每一個應用使用單獨的權限有限的數據庫鏈接。

4.不要把機密信息明文存放，請加密或者hash掉密碼和敏感的信息。

5.應用的異常信息應該給出儘量少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝，把異常信息存放在獨立的表中。

16：spring的工做原理

spring的最大做用ioc/di,將類與類的依賴關係寫在配置文件中，程序在運行時根據配置文件動態加載依賴的類，下降的類與類之間的藕合度。它的原理是在applicationContext.xml加入bean標籤,在bean標籤中經過class屬性說明具體類名、經過property標籤說明該類的屬性名、經過constructor-args說明構造子的參數。其一切都是反射，當經過applicationContext.getBean("id名稱")獲得一個類實例時，就是以bean標籤的類名、屬性名、構造子的參數爲準，經過反射實例對象，喚起對象的set方法設置屬性值、經過構造子的newInstance實例化獲得對象。正由於spring一切都是反射，反射比直接調用的處理速度慢，因此這也是spring的一個問題。

spring第二大做用就是aop，其機理來自於代理模式，代理模式有三個角色分別是通用接口、代理、真實對象代理、真實對象實現的是同一接口，將真實對象做爲代理的一個屬性，向客戶端公開的是代理，當客戶端調用代理的方法時，代理找到真實對象，調用真實對象方法，在調用以前以後提供相關的服務，如事務、安全、日誌。其名稱分別是代理、真實對象、裝備、關切點、鏈接點。

Spring目的：就是讓對象與對象（模塊與模塊）之間的關係沒有經過代碼來關聯，都是經過配置類說明管理的（Spring根據這些配置內部經過反射去動態的組裝對象）

17：Hibernate中java對象的三種狀態的區別

實體對象的生命週期在Hibernate應用中是一個很關鍵的概念,正確的理解實體對象的生命週期將對咱們應用Hibernate作持久層設計起到很大的做用.而所謂的實體對象的生命週期就是指實體對象由產生到被GC回收的一段過程.在這過程當中咱們須要理解的就是實體對象生命週期中的三種狀態.

1.自由狀態(Transient)

2.持久狀態(Persistent)

3.遊離狀態(Detached)

瞬時狀態(臨時狀態) transient：剛剛用new建立，尚未被持久化，不處於Session的緩存中，處於臨時狀態的Java對象被稱爲臨時對象（無數據、無Session）

持久化狀態 persistent：已經被持久化，加入到Session的緩存中。處於持久化狀態的Java對象被稱爲持久化對象（有數據，有Session）

遊離狀態 detached：已經被持久化，但再也不處於Session的緩存中。處於遊離狀態的Java對象被稱爲遊離對象（有數據，無Session）

詳細解析：新new出來的對象如Student stu = new Student(),就是瞬時對象，它在內存中孤立存在，它的意義是攜帶信息的載體，不和數據庫的數據有任何關聯。經過Session的save()或saveOrUpdate()方法能夠把一個瞬時對象與數據庫相關聯，並把瞬時對象攜帶的信息經過配置文件所作的映射插入到數據庫中，這個瞬時對象就轉化成了持久對象(使用get(),load()等方法查詢到的數據對象，一出場就是持久對象)，並擁有和數據庫記錄相同的id標識(Hibernate自動將id值賦予它)。若是這時候使用delete()方法，它就會變回瞬時對象，刪除了數據庫與這個對象關聯的記錄，對象與數據庫再也不有任何的關聯。當一個Session指定close()或clear(),evict()以後，持久對象就變成脫管對象，這時對象的id雖然擁有數據庫識別值，但他們目前並不在Hibernate持久層的管理下，它與瞬時對象的本質是相同的，只不過比瞬時對象多了數據標識的id值。脫管對象的引用依然有效，對象能夠繼續被修改，當它從新被關聯到某個新的Session上時，會再次變成持久對象(脫管狀態期間的改動將被持久化到數據庫上)。脫管對象擁有數據庫識別值id，因此它能夠經過update(),saveOrUpdate(),lock()等方法，再度與持久層關聯。

18：Hibernate的緩存機制

     Hibernate緩存的做用：

Hibernate是一個持久層框架，常常訪問物理數據庫，爲了下降應用程序對物理數據源訪問的頻次，從而提升應用程序的運行性能。緩存內的數據是對物理數據源中的數據的複製，應用程序在運行時從緩存讀寫數據，在特定的時刻或事件會同步緩存和物理數據源的數據

Hibernate緩存分類：

Hibernate緩存包括兩大類：Hibernate一級緩存和Hibernate二級緩存

Hibernate一級緩存又稱爲「Session的緩存」，它是內置的，意思就是說，只要你使用hibernate就必須使用session緩存。因爲Session對象的生命週期一般對應一個數據庫事務或者一個應用事務，所以它的緩存是事務範圍的緩存。在第一級緩存中，持久化類的每一個實例都具備惟一的OID。

Hibernate二級緩存又稱爲「SessionFactory的緩存」，因爲SessionFactory對象的生命週期和應用程序的整個過程對應，所以Hibernate二級緩存是進程範圍或者集羣範圍的緩存，有可能出現併發問題，所以須要採用適當的併發訪問策略，該策略爲被緩存的數據提供了事務隔離級別。第二級緩存是可選的，是一個可配置的插件，在默認狀況下，SessionFactory不會啓用這個插件。

  什麼樣的數據適合存放到第二級緩存中？

1 不多被修改的數據　　

2 不是很重要的數據，容許出現偶爾併發的數據　　

3 不會被併發訪問的數據　　

4 常量數據　　

Hibernate查找對象如何應用緩存？

當Hibernate根據ID訪問數據對象的時候，首先從Session一級緩存中查；查不到，若是配置了二級緩存，那麼從二級緩存中查；若是都查不到，再查詢數據庫，把結果按照ID放入到緩存

刪除、更新、增長數據的時候，同時更新緩存

19：Hibernate是如何延遲加載

延遲加載機制是爲了不一些無謂的性能開銷而提出來的，所謂延遲加載就是當在真正須要數據的時候，才真正執行數據加載操做。Hibernate中主要是經過代理（proxy）機制來實現延遲加載。它的具體過程：Hibernate叢數據庫獲取某一個對象數據時、獲取某一個對象的集合屬性值時，或獲取某一個對象所關聯的另外一個對象時，因爲沒有使用該對象的數據，hibernate並非數據庫加載真正的數據，而只是爲該對象建立一個代理對象來表明這個對象，這個對象上的全部屬性都是默認值；只有在真正須要使用該對象的數據時才建立這個真實對象，真正從數據庫中加載它的數據，這樣在某些狀況下，就能夠提升查詢效率。

集合屬性的延遲加載

當 Hibernate 從數據庫中初始化某個持久化實體時，該實體的集合屬性是否隨持久化類一塊兒初始化呢？若是集合屬性裏包含十萬，甚至百萬的記錄，在初始化持久化實體的同時，完成全部集合屬性的抓取，將致使性能急劇降低。徹底有可能系統只須要使用持久化類集合屬性中的部分記錄，而徹底不是集合屬性的所有，這樣，沒有必要一次加載全部的集合屬性。

對於集合屬性，一般推薦使用延遲加載策略。所謂延遲加載就是等系統須要使用集合屬性時才從數據庫裝載關聯的數據

20：分頁查詢

分頁查詢分爲兩類：邏輯分頁，物理分頁，咱們先從理論上理解一下：

邏輯分頁概述：就是用戶第一次訪問時，將數據庫的全部記錄所有查詢出來，添加到一個大的集合中，而後存放在session對象，而後經過頁碼計算出當前頁須要顯示的數據內容，存儲到一個小的list的集合中，並將之存儲到request對象中，跳轉到JSP頁面，進行遍歷顯示。當用戶第二次訪問時，只要不關閉瀏覽器，咱們還會從session中獲取數據，來進行顯示。爲何叫邏輯分頁呢？由於此種方法是在內存的session對象中進行計算分頁顯示的，而不是真正的將咱們數據庫進行分頁的。

缺點：

a，若是須要查詢的數據量過大，session將耗費大量的內存；

b，由於是在session中獲取數據，若是第二次或者更多此的不關閉瀏覽器訪問，會直接訪問session，從而不能保證數據是最新的。

小結：這種分頁不多使用。可是在數據量小，不會被修改的數據，使用邏輯分頁會提升程序的執行效率。

物理分頁概述：使用數據庫自身所帶的分頁機制，例如，Oracle數據庫的rownum，或者Mysql數據庫中的limit等機制來完成分頁操做。由於是對數據庫實實在在的數據進行分頁條件查詢，因此叫物理分頁。每一次物理分頁都會去鏈接數據庫。

優勢：數據可以保證最新，因爲根據分頁條件會查詢出少許的數據，因此不會佔用太多的內存。

缺點：物理分頁使用了數據庫自身帶的機制，因此這樣的SQL語句不通用，致使不能進行數據庫的移植。

小結：在實際中物理分頁仍是使用的較多的。

21：forward和redirect

redirect：請求重定向：客戶端行爲，本質上爲2次請求，地址欄改變，前一次請求對象消失，是服務器向用戶發送轉向的地址，redirect後地址欄變成新的地址。

forward：請求轉發:服務器行爲，服務器獲取跳轉頁面內容傳給用戶，用戶地址欄不變

重定向和轉發有一個重要的不一樣：當使用轉發時，JSP容器將使用一個內部的方法來調用目標頁面，新的頁面繼續處理同一個請求，而瀏覽器將不會知道這個過程。與之相反，重定向方式的含義是第一個頁面通知瀏覽器發送一個新的頁面請求。由於，當你使用重定向時，瀏覽器中所顯示的URL會變成新頁面的URL, 而當使用轉發時，該URL會保持不變。重定向的速度比轉發慢，由於瀏覽器還得發出一個新的請求。同時，因爲重定向方式產生了一個新的請求，因此通過一次重定向後，request內的對象將沒法使用。
怎麼選擇是重定向仍是轉發呢？一般狀況下轉發更快，並且能保持request內的對象，因此他是第一選擇。可是因爲在轉發以後，瀏覽器中URL仍然指向開始頁面，此時若是重載當前頁面，開始頁面將會被從新調用。若是你不想看到這樣的狀況，則選擇轉發

22：HashMap底層數據結構和原理

底層數據結構：

HashMap其實是一個「鏈表的數組」的數據結構，每一個元素存放鏈表頭結點的數組，即數組和鏈表的結合體。

當咱們往HashMap中put元素的時候，先根據key的hashCode從新計算hash值，根據hash值獲得這個元素在數組中的位置（即下標），若是數組該位置上已經存放有其餘元素了，那麼在這個位置上的元素將以鏈表的形式存放，新加入的放在鏈頭，最早加入的放在鏈尾。若是數組該位置上沒有元素，就直接將該元素放到此數組中的該位置上

從HashMap中get元素時，首先計算key的hashCode，找到數組中對應位置的某一元素，而後經過key的equals方法在對應位置的鏈表中找到須要的元素。

總結：HashMap 在底層將 key-value 當成一個總體進行處理，這個總體就是一個 Entry 對象。HashMap 底層採用一個 Entry[] 數組來保存全部的 key-value 對，當須要存儲一個 Entry 對象時，會根據hash算法來決定其在數組中的存儲位置，在根據equals方法決定其在該數組位置上的鏈表中的存儲位置；當須要取出一個Entry時，也會根據hash算法找到其在數組中的存儲位置，再根據equals方法從該位置上的鏈表中取出該Entry。

HashMap(線程不安全)與HashTable(線程安全)的區別

(1)二者最主要的區別在於Hashtable是線程安全，而HashMap則非線程安全
Hashtable的實現方法裏面都添加了synchronized關鍵字來確保線程同步，所以相對而言HashMap性能會高一些，咱們平時使用時若無特殊需求建議使用HashMap，在多線程環境下若使用HashMap須要使用Collections.synchronizedMap()方法來獲取一個線程安全的集合（Collections.synchronizedMap()實現原理是Collections定義了一個SynchronizedMap的內部類，這個類實現了Map接口，在調用方法時使用synchronized來保證線程同步,固然了實際上操做的仍是咱們傳入的HashMap實例，簡單的說就是Collections.synchronizedMap()方法幫咱們在操做HashMap時自動添加了synchronized來實現線程同步，相似的其它Collections.synchronizedXX方法也是相似原理）

(2) HashMap和Hashtable的底層實現都是數組+鏈表結構實現

(3) HashMap可使用null做爲key，而Hashtable則不容許null做爲key
雖然說HashMap支持null值做爲key，不過建議仍是儘可能避免這樣使用，由於一旦不當心使用了，若所以引起一些問題，排查起來非常費事
HashMap以null做爲key時，老是存儲在table數組的第一個節點上

(4) HashMap是對Map接口的實現，HashTable實現了Map接口和Dictionary抽象類

22: String、StringBuffer(線程安全)、StringBuilder(線程不安全)區別

StringBuffer、StringBuilder和String同樣，也用來表明字符串。String類是不可變類，任何對String的改變都會引起新的String對象的生成；StringBuffer則是可變類，任何對它所指代的字符串的改變都不會產生新的對象。既然可變和不可變都有了，爲什麼還有一個StringBuilder呢？相信初期的你，在進行append時，通常都會選擇StringBuffer吧！

先說一下集合的故事，HashTable是線程安全的，不少方法都是synchronized方法，而HashMap不是線程安全的，但其在單線程程序中的性能比HashTable要高。StringBuffer和StringBuilder類的區別也是如此，他們的原理和操做基本相同，區別在於StringBuffer支持併發操做，線性安全的，適合多線程中使用。StringBuilder不支持併發操做，線性不安全的，不適合多線程中使用。新引入的StringBuilder類不是線程安全的，但其在單線程中的性能比StringBuffer高。

23：java中的四種引用類型

⑷ 強引用（StrongReference）、⑵軟引用（SoftReference）、⑶弱引用（WeakReference）、

⑷虛引用（PhantomReference）

24：java的基礎類型和字節

java四類八種基本數據類型

第一類：整型 byte short int long
第二類：浮點型 float double

第三類：邏輯型 boolean(它只有兩個值可取true false)

第四類：字符型 char

引用數據類型：是數據的引用在棧中，可是他的對象在堆中。在棧中能夠直接分配內存的數據是基本數據類型。
  字節：
    boolean 布爾型              1/8
    byte 字節類型                1
    char 字符型                  2 一個字符能存儲一箇中文漢字
    short 短整型                 2
    int 整數類型                 4
    float 浮點類型（單精度）     4
    long 長整形                  8
    double 雙精度類型（雙精度） 8

25：調用start()方法和run()的區別

  區別：調用start方法實現多線程，而調用run方法沒有實現多線程

Start:

   用start方法來啓動線程，真正實現了多線程運行，這時無需等待run方法體代碼執行完畢而直接繼續執行下面的代碼。經過調用Thread類的start()方法來啓動一個線程，這時此線程處於就緒（可運行）狀態，並無運行，一旦獲得spu時間片，就開始執行run()方法，這裏方法run()稱爲線程體，它包含了要執行的這個線程的內容，Run方法運行結束，此線程隨即終止。

Run:

  run()方法只是類的一個普通方法而已，若是直接調用Run方法，程序中依然只有主線程這一個線程，其程序執行路徑仍是隻有一條，仍是要順序執行，仍是要等待run方法體執行完畢後纔可繼續執行下面的代碼，這樣就沒有達到寫線程的目的。

總結：調用start方法方可啓動線程，而run方法只是thread的一個普通方法調用，仍是在主線程裏執行。

26：實現多線程有幾種方式，多線程同步怎麼作

實現線程有2種方式：繼承Thread類或者實現Runnable接口

實現同步也有兩種方式，一種是用同步方法，另外一種是用同步塊

27：http中，get post的區別

Http定義了與服務器交互的不一樣方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE。URL全稱是資源描述符，咱們能夠這樣認爲：一個URL地址，它用於描述一個網絡上的資源，而HTTP中的GET，POST，PUT，DELETE就對應着對這個資源的查，改，增，刪4個操做。到這裏，你們應該有個大概的瞭解了，GET通常用於獲取/查詢資源信息，而POST通常用於更新資源信息

1.根據HTTP規範，GET用於信息獲取，並且應該是安全的和冪等的。

2.根據HTTP規範，POST表示可能修改變服務器上的資源的請求

不少人卻沒有按照HTTP規範去作，致使這個問題的緣由有不少，好比說：

1.不少人貪方便，更新資源時用了GET，由於用POST必需要到FORM（表單），這樣會麻煩一點。

　　2.對資源的增，刪，改，查操做，其實均可以經過GET/POST完成，不須要用到PUT和DELETE。

　　3.另一個是，早期的Web MVC框架設計者們並無有意識地將URL看成抽象的資源來看待和設計，因此致使一個比較嚴重的問題是傳統的Web MVC框架基本上都只支持GET和POST兩種HTTP方法，而不支持PUT和DELETE方法

表面現象上面看看GET和POST的區別：

1.GET請求的數據會附在URL以後（就是把數據放置在HTTP協議頭中），以?分割URL和傳輸數據，參數之間以&相連，如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD。若是數據是英文字母/數字，原樣發送，若是是空格，轉換爲+，若是是中文/其餘字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX爲該符號以16進製表示的ASCII。

　　POST把提交的數據則放置在是HTTP包的包體中。

2."GET方式提交的數據最多隻能是1024字節，理論上POST沒有限制，可傳較大量的數據

實際解釋：

(1).首先是"GET方式提交的數據最多隻能是1024字節"，由於GET是經過URL提交數據，那麼GET可提交的數據量就跟URL的長度有直接關係了。而實際上，URL不存在參數上限的問題，HTTP協議規範沒有對URL長度進行限制。這個限制是特定的瀏覽器及服務器對它的限制。IE對URL長度的限制是2083字節(2K+35)。對於其餘瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決於操做系統的支持。

　　注意這是限制是整個URL長度，而不只僅是你的參數值數據長度。

(2).理論上講，POST是沒有大小限制的，HTTP協議規範也沒有進行大小限制，說「POST數據量存在80K/100K的大小限制」是不許確的，POST數據是沒有限制的，起限制做用的是服務器的處理程序的處理能力。

裏外一種答案方式：

GET方法：

使用GET方法時，查詢字符串（鍵值對）被附加在URL地址後面一塊兒發送到服務器：

/test/demo_form.jsp?name1=value1&name2=value2

特色：

GET請求可以被緩存

GET請求會保存在瀏覽器的瀏覽記錄中

以GET請求的URL可以保存爲瀏覽器書籤

GET請求有長度限制

GET請求主要用以獲取數據

POST方法：

使用POST方法時，查詢字符串在POST信息中單獨存在，和HTTP請求一塊兒發送到服務器：

POST /test/demo_form.jsp HTTP/1.1

Host: w3schools.com

name1=value1&name2=value2

特色：

POST請求不能被緩存下來

POST請求不會保存在瀏覽器瀏覽記錄中

以POST請求的URL沒法保存爲瀏覽器書籤

POST請求沒有長度限制

28：訪問一個網站的過程

首先是查找瀏覽器緩存，瀏覽器會保存一段時間你以前訪問過的一些網址的DNS信息，不一樣瀏覽器保存的時常不等。若是沒有找到對應的記錄，這個時候瀏覽器會嘗試調用系統緩存來繼續查找這個網址的對應DNS信息。若是仍是沒找到對應的IP，那麼接着會發送一個請求到路由器上，而後路由器在本身的路由器緩存上查找記錄，路由器通常也存有DNS信息。若是仍是沒有，這個請求就會被髮送到ISP(（注：Internet Service Provider，互聯網服務提供商) ，ISP也會有相應的ISP DNS服務器，若是仍是沒有的話，你的ISP的DNS服務器會將請求發向根域名服務器進行搜索。根域名服務器就是面向全球的頂級DNS服務器，共有13臺邏輯上的服務器，從A到M命名，真正的實體服務器則有幾百臺，分佈於全球各大洲。因此這些服務器有真正完整的DNS數據庫。若是到了這裏仍是找不到域名的對應信息，那隻能說明一個問題：這個域名原本就不存在，它沒有在網上正式註冊過。

這也就是爲何打開一個新頁面會有點慢，由於本地沒什麼緩存，要這樣遞歸地查詢下去。

多說一句，例如"mp3.baidu.com"，域名先是解析出這是個.com的域名，而後跑到管理.com域名的服務器上進行進一步查詢，而後是.baidu，最後是mp3，

因此域名結構爲：三級域名.二級域名.一級域名。

瀏覽器終於獲得了IP之後，瀏覽器接着給這個IP的服務器發送了一個http請求，方式爲get

這個get請求包含了主機（host）、用戶代理(User-Agent)，用戶代理就是本身的瀏覽器，它是你的"代理人"，Connection（鏈接屬性）中的keep-alive表示瀏覽器告訴對方服務器在傳輸完如今請求的內容後不要斷開鏈接，不斷開的話下次繼續鏈接速度就很快了。其餘的顧名思義就好了。還有一個重點是Cookies，Cookies保存了用戶的登錄信息，在每次向服務器發送請求的時候會重複發送給服務器, 服務器收到瀏覽器的請求之後（實際上是WEB服務器接收到了這個請求，WEB服務器有iis、apache等），它會解析這個請求（讀請求頭），而後生成一個響應頭和具體響應內容。接着服務器會傳回來一個響應頭和一個響應，響應頭告訴了瀏覽器一些必要的信息，例如重要的Status Code，2開頭如200表示一切正常，3開頭表示重定向，4開頭，如404，呵呵。響應就是具體的頁面編碼，就是那個<html>......</html>，瀏覽器先讀了關於這個響應的說明書（響應頭），而後開始解析這個響應並在頁面上顯示出來。

簡化事後就是下面這個過程：

1.DNS域名解析：瀏覽器緩存、系統緩存、路由器、ISP的DNS服務器、根域名服務器。把域名轉化成IP地址。

2.與IP地址對應的服務器創建TCP鏈接，經歷三次握手：SYN，ACK、SYN，ACK

3.以get，post方式發送HTTP請求，get方式發送主機，用戶代理，connection屬性，cookie等

4.得到服務器的響應，顯示頁面

29：單點登錄的原理

單點登陸在如今的系統架構中普遍存在，他將多個子系統的認證體系打通，實現了一個入口多處使用，而在架構單點登陸時，也會遇到一些小問題，在不一樣的應用環境中能夠採用不一樣的單點登陸實現方案來知足需求。

單點登陸機制：（1）；根據用戶提供的登陸信息，認證系統進行身份效驗，若是經過效驗，應該返回給用戶一個認證的憑據－－ticket（2）；用戶再訪問別的應用的時候就會將這個ticket帶上，做爲本身認證的憑據，應用系統接受到請求以後會把ticket送到認證系統進行效驗，檢查ticket的合法性。若是經過效驗，用戶就能夠在不用再次登陸的狀況下訪問應用系統了。

使用cookie和session等解決也能夠

30： Cookie和Session的區別

Cookies是服務器在本地機器上存儲的小段文本並隨每個請求發送至同一個服務器

Session機制採用的是一種在服務器端保持狀態的解決方案，因爲採用服務器端保持狀態的方案在客戶端也須要保存一個標識，因此session機制可能須要藉助於cookie機制來達到保存標識的目的。而session提供了方便管理全局變量的方式。session是針對每個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪一個用戶session變量,這個值是經過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置爲由get來返回給服務器。

1 .存取方式的不一樣

Cookie中只能保管ASCII字符串，假如需求存取Unicode字符或者二進制數據，需求先進行編碼。Cookie中也不能直接存取Java對象。

Session中可以存取任何類型的數據，包括而不限於String、Integer、List、Map等。Session中也可以直接保管Java Bean乃至任何Java類，對象等，運用起來十分便當。可以把Session看作是一個Java容器類。

2 .隱私策略的不一樣

Cookie存儲在客戶端閱讀器中，對客戶端是可見的，客戶端的一些程序可能會窺探、複製以致修正Cookie中的內容。而Session存儲在服務器上，對客戶端是透明的，不存在敏感信息泄露的風險。

3.服務器壓力的不一樣

Session是保管在服務器端的，每一個用戶都會產生一個Session。假如併發訪問的用戶十分多，會產生十分多的Session，耗費大量的內存。於是像Google、Baidu、Sina這樣併發訪問量極高的網站，是不太可能運用Session來追蹤客戶會話的。

而Cookie保管在客戶端，不佔用服務器資源。假如併發閱讀的用戶十分多，Cookie是很好的選擇。關於Google、Baidu、Sina來講，Cookie或許是惟一的選擇

31: 如何進行跨機房數據同步？如何保證數據訪問的一致性

Master/Slave方案

這是最經常使用的方案，適用於大多數需求。Master將操做日誌實時地發送到Slave，Slave當成Master的一個Hot Backup。Master宕機時，服務切換到Slave，須要修改客戶端邏輯使得Master失效時自動尋找新的Master。

Zookeeper消息分發機制

32：數據庫鏈接池

經常使用的幾種鏈接池：DBCP、c3p0、proxool

原理：數據庫鏈接池實際上就是在程序加載時就按照設置的數量先和數據庫創建必定量的鏈接，當須要數據庫鏈接時就直接從最開始創建的鏈接中取得所須要的鏈接就行。當不須要時，只須要將鏈接還給鏈接池；當創建的鏈接被取用完後，而且還存在後續的請求，也就是說如今的鏈接數量已經超過了系統設置的最大鏈接數。那麼，後面的請求只有等待！！

33：http，socket，tcp/ip 網絡傳輸與通信知識總結

什麼是TCP和UDP，以及兩者區別是什麼？
TCP的全稱爲傳輸控制協議。這種協議能夠提供面向鏈接的、可靠的、點到點的通訊。
UDP全稱爲用戶數據報協議，它能夠提供非鏈接的不可靠的點到多點的通訊。
使用TCP仍是UDP，那要看你的程序注重哪個方面，可靠（tcp）仍是快速（udp）。

HTTP鏈接
HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網經常使用的協議之一，HTTP協議是創建在TCP協議之上的一種應用。
HTTP鏈接最顯著的特色是客戶端發送的每次請求都須要服務器回送響應，在請求結束後，會主動釋放鏈接。從創建鏈接到關閉鏈接的過程稱爲「一次鏈接」。

SOCKET原理

套接字（socket）是通訊的基石，是支持TCP/IP協議的網絡通訊的基本操做單元。它是網絡通訊過程當中端點的抽象表示，包含進行網絡通訊必須的五種信息：鏈接使用的協議，本地主機的IP地址，本地進程的協議端口，遠地主機的IP地址，遠地進程的協議端口。
應用層經過傳輸層進行數據通訊時，TCP會遇到同時爲多個應用程序進程提供併發服務的問題。多個TCP鏈接或多個應用程序進程可能須要經過同一個 TCP協議端口傳輸數據。爲了區別不一樣的應用程序進程和鏈接，許多計算機操做系統爲應用程序與TCP／IP協議交互提供了套接字(Socket)接口。應用層能夠和傳輸層經過Socket接口，區分來自不一樣應用程序進程或網絡鏈接的通訊，實現數據傳輸的併發服務

創建SOCKET鏈接
創建Socket鏈接至少須要一對套接字，其中一個運行於客戶端，稱爲ClientSocket ，另外一個運行於服務器端，稱爲ServerSocket 。
套接字之間的鏈接過程分爲三個步驟：服務器監聽，客戶端請求，鏈接確認。

1.)服務器監聽：服務器端套接字並不定位具體的客戶端套接字，而是處於等待鏈接的狀態，實時監控網絡狀態，等待客戶端的鏈接請求。
2.)客戶端請求：指客戶端的套接字提出鏈接請求，要鏈接的目標是服務器端的套接字。爲此，客戶端的套接字必須首先描述它要鏈接的服務器的套接字，指出服務器端套接字的地址和端口號，而後就向服務器端套接字提出鏈接請求。
3.)鏈接確認：當服務器端套接字監聽到或者說接收到客戶端套接字的鏈接請求時，就響應客戶端套接字的請求，創建一個新的線程，把服務器端套接字的描述發給客戶端，一旦客戶端確認了此描述，雙方就正式創建鏈接。而服務器端套接字繼續處於監聽狀態，繼續接收其餘客戶端套接字的鏈接請求。

SOCKET鏈接與TCP/IP鏈接

建立Socket鏈接時，能夠指定使用的傳輸層協議，Socket能夠支持不一樣的傳輸層協議（TCP或UDP），當使用TCP協議進行鏈接時，該Socket鏈接就是一個TCP鏈接。

SOCKET鏈接與HTTP鏈接

因爲一般狀況下Socket鏈接就是TCP鏈接，所以Socket鏈接一旦創建，通訊雙方便可開始相互發送數據內容，直到雙方鏈接斷開。但在實際網絡應用中，客戶端到服務器之間的通訊每每須要穿越多箇中間節點，例如路由器、網關、防火牆等，大部分防火牆默認會關閉長時間處於非活躍狀態的鏈接而致使 Socket 鏈接斷連，所以須要經過輪詢告訴網絡，該鏈接處於活躍狀態。

而HTTP鏈接使用的是「請求—響應」的方式，不只在請求時須要先創建鏈接，並且須要客戶端向服務器發出請求後，服務器端才能回覆數據。
不少狀況下，須要服務器端主動向客戶端推送數據，保持客戶端與服務器數據的實時與同步。
若雙方創建的是Socket鏈接，服務器就能夠直接將數據傳送給客戶端；
若雙方創建的是HTTP鏈接，則服務器須要等到客戶端發送一次請求後才能將數據傳回給客戶端。
所以，客戶端定時向服務器端發送鏈接請求，不只能夠保持在線，同時也是在「詢問」服務器是否有新的數據，若是有就將數據傳給客戶端

實際上，傳輸層的TCP是基於網絡層的IP協議的，而應用層的HTTP協議又是基於傳輸層的TCP協議的，而Socket自己不算是協議，就像上面所說，它只是提供了一個針對TCP或者UDP編程的接口。

34：設計模式

整體來講設計模式分爲三大類：

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

結構型模式 共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

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

單例模式：始終是一個對象實例.它對外不提供構造函數,所以咱們不可以同時產生多個對象.

單例模式有如下特色：
　　一、單例類只能有一個實例。
　　二、單例類必須本身建立本身的惟一實例。
　　三、單例類必須給全部其餘對象提供這一實例。

//懶漢式單例類.在第一次調用的時候實例化本身
public class Singleton {
private Singleton() {}
private static Singleton single=null;
//靜態工廠方法
public static Singleton getInstance() {
if (single == null) {
single = new Singleton();
}
10. return single;
11. }

12. }

以上懶漢式單例的實現沒有考慮線程安全問題，它是線程不安全的，併發環境下極可能出現多個Singleton實例，要實現線程安全，能夠在getInstance()上加同步

public static synchronized Singleton getInstance() {
if (single == null) {
single = new Singleton();
}
return single;
}

餓漢式單例模式

//餓漢式單例類.在類初始化時，已經自行實例化
public class Singleton1 {
private Singleton1() {}
private static final Singleton1 single = new Singleton1();
//靜態工廠方法
public static Singleton1 getInstance() {
return single;
}
}

餓漢式在類建立的同時就已經建立好一個靜態的對象供系統使用，之後再也不改變，因此天生是線程安全的

應用場景：常見的工具類、數據庫鏈接類就能夠定義爲單例類

35：數據庫存儲過程觸發器函數

mysql 執行語句是要先編譯，而後再執行的。這樣若是查詢併發大的時候。會浪費不少資源和時間。形成mysql進程佔用資源過多，症狀就是慢。但存儲過程能夠把一些特別的語句封裝成一個方法，再編譯好成一個能夠執行的方法，對外只要接收參數就能夠了。這樣就不用再編譯。執行就快了
何時會用到？你以爲你數據庫由於同時出現太多讀寫操做而變得慢，那麼就要用了。

存儲過程（Stored Procedure）是一組爲了完成特定功能的SQL語句集，經編譯後存儲在數據庫中，用戶經過指定存儲過程的名字並給定參數（若是該存儲過程帶有參數）來調用執行它。

觸發器是特殊的存儲過程，存儲過程須要程序調用，而觸發器會自動執行；你所說的函數是自定義函數吧，函數是根據輸入產生輸出，自定義只不過輸入輸出的關係由用戶來定義。在何時用觸發器？要求系統根據某些操做自動完成相關任務，好比，根據買掉的產品的輸入數量自動扣除該產品的庫存量。何時用存儲過程？存儲過程就是程序，它是通過語法檢查和編譯的SQL語句，因此運行特別快。

36：數據庫優化

(1) sql語句優化

不要在數據庫中作運算

避免負向查詢和%前綴模糊查詢

不在索引列作運算或者使用函數

不要在生產環境程序中使用select * from 的形式查詢數據。只查詢須要使用的列

查詢儘量使用limit減小返回的行數，減小數據傳輸時間和帶寬浪費

where子句儘量對查詢列使用函數，由於對查詢列使用函數用不到索引

應儘可能避免在 where 子句中對字段進行 null 值判斷，不然將致使引擎放棄使用索引而進行全表掃描

(2) 添加適當的索引，索引對查詢速度影響很大，必須添加索引。主鍵索引，惟一索引，普通索引，全文索引選擇適當的字段類型，特別是主鍵

(3) 文件、圖片等大文件用文件系統存儲，不用數據庫

(4) 使用數據緩存

(5) 讀寫分離（主從數據庫）

(6) 分表分區分表：把一張大表分紅多張表。分區：把一張表裏面的分配到不一樣的區域存儲，

(7) 添加適當存儲過程，觸發器，事務等

37: Ajax

Ajax是(Asynchronous JavaScript And XML)是異步的JavaScript和xml。也就是異步請求更新技術。

其運行原理就至關於建立了一個請求代理，經過代理去完成與服務器的交互，交互的過程當中客戶不須要等待，還能夠進行其它的工做，交互完成之後，代理再將交互的結果返回給客戶頁面

執行步驟：

第一步:建立xmlHttpRequest對象，每一個瀏覽器的建立不是都相同。一般狀況下爲了兼容全部瀏覽器，每一個都要寫上。

第二步：設置open（）方法和setRequestHeader()方法參數。

將請求方式，請求目的地址，和請求類型設置到open方法中，若是是post請求，則須要設置setRequestHeader()參數

第三步：發送執行。利用send方法，與服務器真正的交互執行

第四步：得到執行結果。首先判斷執行是否完成，而後經過js操做dom元素，將返回的responseText返回到頁面

38：sql 視圖和表的區別

數據庫中的數據都是存儲在表中的，而視圖只是一個或多個表依照某個條件組合而成的結果集，通常來講你能夠用update，insert，delete等sql語句修改表中的數據，而對視圖只能進行select操做

表是物理存在的，你能夠理解成計算機中的文件！
視圖是虛擬的內存表，你能夠理解成Windows的快捷方式！

區別：一、視圖是已經編譯好的sql語句。而表不是
  二、視圖沒有實際的物理記錄。而表有。
  三、表是內容，視圖是窗口
  四、表只用物理空間而視圖不佔用物理空間，視圖只是邏輯概念的存在，表能夠及時對它進行修改，但視圖只能有建立的語句來修改
   五、表是內模式，視圖是外模式
   六、視圖是查看數據表的一種方法，能夠查詢數據表中某些字段構成的數據，只是一些SQL語句的集合。從安全的角度說，視圖能夠不給用戶接觸數據表，從而不知道表結構。
   七、表屬於全局模式中的表，是實表；視圖屬於局部模式的表，是虛表。
    八、視圖的創建和刪除隻影響視圖自己，不影響對應的基本表。

使用視圖的好處：

　第一點：使用視圖，能夠定製用戶數據，聚焦特定的數據。

第二點：使用視圖，能夠簡化數據操做。

第三點：使用視圖，基表中的數據就有了必定的安全性

第四點：能夠合併分離的數據，建立分區視圖

39：CSS相關盒子模型

Div居中：margin:0 auto; 在添加一個寬度

40：服務器端開發須要的知識點

多進程、多線程：

進程優勢：編程、調試簡單，可靠性較高。
進程缺點：建立、銷燬、切換速度慢，內存、資源佔用大。
線程優勢：建立、銷燬、切換速度快，內存、資源佔用小。
線程缺點：編程、調試複雜，可靠性較差。

socket開發模型

socket通訊在客戶端和服務器端進行，主要包括

服務器端行爲：

1：服務器端建立套接字，s = socket.socket() ; 2：綁定套接字到本地ip和端口號， s.bind(ip_port); 3：監聽鏈接, s.listen(n)；4:接受客戶端創建鏈接的請求，conn,addr = s.accept(); 5：接受客戶端的消息，並作出相應處理 recv_data = conn.recv(1024); 6 : 給客戶端回消息，conn.send(send_data); 7:關閉鏈接；

客戶端行爲：

1：建立套接字； 2：鏈接服務器； 3：給服務器發消息； 4：接受服務器消息； 5：關閉鏈接；

SocketServer實現支持多客戶端

SocketServer內部使用 IO多路複用以及「多線程」和「多進程」，從而實現併發處理多個客戶端請求的Socket服務端。即：每一個客戶端請求鏈接到服務器時，Socket服務端都會在服務器是建立一個「線程」或者「進程」專門負責處理當前客戶端的全部請求

分佈式系統概念

1. 熟悉Unix/Linux系統者優先；

2. 熟悉Shell腳本者優先。

41：linux下進程間的通訊

方法：管道、消息隊列、共享內存、信號量、套接口等等

共享內存：共享內存是運行在同一臺機器上的進程間通訊最快的方式，由於數據不須要在不一樣的進程間複製。一般由一個進程建立一塊共享內存區，其他進程對這塊內存區進行讀寫

42：樂觀鎖/悲觀鎖

悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認爲別人會修改，因此每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關係型數據庫裏邊就用到了不少這種鎖機制，好比行鎖，表鎖等，讀鎖，寫鎖等，都是在作操做以前先上鎖。

樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數據的時候都認爲別人不會修改，因此不會上鎖，可是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣能夠提升吞吐量，像數據庫若是提供相似於write_condition機制的其實都是提供的樂觀鎖。

兩種鎖各有優缺點，不可認爲一種好於另外一種，像樂觀鎖適用於寫比較少的狀況下，即衝突真的不多發生的時候，這樣能夠省去了鎖的開銷，加大了系統的整個吞吐量。但若是常常產生衝突，上層應用會不斷的進行retry，這樣反卻是下降了性能，因此這種狀況下用悲觀鎖就比較合適。

43：java中實現同步的幾種方法

1：同步方法

即有synchronized關鍵字修飾的方法。

因爲java的每一個對象都有一個內置鎖，當用此關鍵字修飾方法時，

內置鎖會保護整個方法。在調用該方法前，須要得到內置鎖，不然就處於阻塞狀態。

例子：public synchronized void save(){}

2：同步代碼塊

即有synchronized關鍵字修飾的語句塊。

被該關鍵字修飾的語句塊會自動被加上內置鎖，從而實現同步

例子：synchronized(object){

}