032 Java再次總結

1.大綱redis

  多線程怎麼用的,線程池,事務,傳播機制與隔離級別,反射,泛型,數據庫引擎的區別,數據庫merge,窗口函數,fastJson,JVM調優,GC鉤子,Linux的awk,shell,HashMap在1.7與1.8的結構區別,quartz串行調度怎麼控制,集羣參數,kafka怎麼不第二次消費,單點登陸原理,AOP,IOC,內存刷新,ZK,BlockingQueue,網關,mybatis,storm怎麼動態實時,RPC,ES,RDD,boot,redis,row_id,操做系統,數據結構,算法,網絡。算法

 

一:多線程shell

1.優缺點數據庫

  優勢:服務器

  (1)多線程技術使程序的響應速度更快網絡

  (2)當前沒有進行處理的任務能夠將處理器時間讓給其它任務數據結構

  (3)佔用大量處理時間的任務能夠按期將處理器時間讓給其它任務mybatis

  (4)能夠隨時中止任務多線程

  (5)能夠分別設置各個任務的優先級以及優化性能jvm

  缺點:

  (1)等候使用共享資源時形成程序的運行速度變慢

  (2)對線程進行管理要求額外的cpu開銷

  (3)可能出現線程死鎖狀況。即較長時間的等待或資源競爭以及死鎖等症狀。

 

2. start()方法和run()方法簡介和區別?

  start()方法:

  1)用start方法來啓動線程,真正實現了多線程運行,這時無需等待run方法體代碼執行完畢而直接繼續執行下面的代碼。

  2)經過調用Thread類的start()方法來啓動一個線程,這時此線程處於就緒(可運行)狀態,並無運行,一旦獲得CPU時間片,就開始執行run()方法。

  run()方法:

  1)run()方法只是類的一個普通方法而已,若是直接調用Run方法,程序中依然只有主線程這一個線程,其程序執行路徑仍是隻有一條。

  總結:

  1)調用start方法方可啓動線程,

  2)而run方法只是thread的一個普通方法調用,仍是在主線程裏執行。

  3)把須要並行處理的代碼放在run()方法中,start()方法啓動線程將自動調用run()方法,這是由jvm的內存機制規定的。

  4)而且run()方法必須是public訪問權限,返回值類型爲void.。

 

3.Runnable接口和Callable接口的相同點和不一樣點?

  

 

4.

 

 

 

 

3.三次握手

  

  第一次

  第一次握手:創建鏈接時, 客戶端發送 syn包(syn=j)到 服務器,並進入 SYN_SENT狀態,等待服務器確認;SYN:同步序列編號( Synchronize Sequence Numbers)。

  第二次

  第二次握手服務器收到 syn包,必須確認客戶的SYN( ack=j+1),同時本身也發送一個SYN包(syn=k),即SYN+ACK包,此時服務器進入 SYN_RECV狀態;

  第三次

  第三次握手: 客戶端收到 服務器的SYN+ACK包,向 服務器發送確認包ACK( ack=k+1),此包發送完畢,客戶端和服務器進入 ESTABLISHED(TCP鏈接成功)狀態,完成三次握手。
完成三次握手, 客戶端與服務器開始傳送 數據

  首先很是明確的是兩次握手是最基本的。第一次握手,客戶端發了個鏈接請求消息到服務端,服務端收到信息後知道本身與客戶端是能夠鏈接成功的,但此時客戶端並不知道服務端是否已經接收到了它的請求,因此服務端接收到消息後的應答,客戶端獲得服務端的反饋後,才肯定本身與服務端是能夠鏈接上的,這就是第二次握手。

  客戶端只有肯定了本身能與服務端鏈接上才能開始發數據。因此兩次握手確定是最基本的。

  看到這裏,你或許會問,那麼爲何須要第三次握手呢?咱們來看一下,假設一下若是沒有第三次握手,而是兩次握手後咱們就認爲鏈接成功了,那麼會發生什麼?第三次握手是爲了防止已經失效的鏈接請求報文段忽然又傳到服務端,於是產生錯誤。

  譬如發起請求遇到相似這樣的狀況:客戶端發出去的第一個鏈接請求因爲某些緣由在網絡節點中滯留了致使延遲,直到鏈接釋放的某個時間點纔到達服務端,這是一個早已失效的報文,可是此時服務端仍然認爲這是客戶端的創建鏈接請求第一次握手,因而服務端迴應了客戶端,第二次握手。

  若是隻有兩次握手,那麼到這裏,鏈接就創建了,可是此時客戶端並無任何數據要發送,而服務端還在傻傻的等候佳音,形成很大的資源浪費。因此須要第三次握手,只有客戶端再次迴應一下,就能夠避免這種狀況。
 
2.quartz怎麼實現串行的任務調度
相關文章
相關標籤/搜索