基礎篇
基本功
面向對象特征
封裝,繼承,多態和抽象
-
封裝
封裝給對象提供了隱藏內部特性和行為的能力。對象提供一些能被其他對象訪問的方法來改
變它內部的數據。在 Java 當中,有 3 種修飾符: public, private 和 protected。每一種修飾符
給其他的位於同一個包或者不同包下面對象賦予了不同的訪問權限。
下面列出了使用封裝的一些好處:- 通過隱藏對象的屬性來保護對象內部的狀態。
- 提高了代碼的可用性和可維護性,因為對象的行為可以被單獨的改變或者是擴展。
- 禁止對象之間的不良交互提高模塊化
-
繼承
繼承給對象提供了從基類獲取字段和方法的能力。繼承提供了代碼的重用行,也可以在不修改類的情況下給現存的類添加新特性。 -
多態
多態是編程語言給不同的底層數據類型做相同的接口展示的一種能力。一個多態類型上的操作可以應用到其他類型的值上面。 -
抽象
抽象是把想法從具體的實例中分離出來的步驟,因此,要根據他們的功能而不是實現細節來創建類。 Java 支持創建只暴漏接口而不包含方法實現的抽象的類。這種抽象技術的主要目的是把類的行為和實現細節分離開。
final, finally, finalize 的區別
-
final
修飾符(關鍵字)如果一個類被聲明為final,意味着它不能再派生出新的子類,不能作為父類被繼承。因此一個類不能既被聲明為 abstract的,又被聲明為final的。將變量或方法聲明為final,可以保證它們在使用中不被改變。被聲明為final的變量必須在聲明時給定初值,而在以后的引用中只能讀取,不可修改。被聲明為final的方法也同樣只能使用,不能重載。 -
finally
在異常處理時提供 finally 塊來執行任何清除操作。如果拋出一個異常,那么相匹配的 catch 子句就會執行,然后控制就會進入 finally 塊(如果有的話)。 -
finalize
方法名。Java 技術允許使用 finalize() 方法在垃圾收集器將對象從內存中清除出去之前做必要的清理工作。這個方法是由垃圾收集器在確定這個對象沒有被引用時對這個對象調用的。它是在 Object 類中定義的,因此所有的類都繼承了它。子類覆蓋 finalize() 方法以整理系統資源或者執行其他清理工作。finalize() 方法是在垃圾收集器刪除對象之前對這個對象調用的。
int 和 Integer 有什么區別
int 是基本數據類型
Integer是其包裝類,注意是一個類。
為什么要提供包裝類呢???
一是為了在各種類型間轉化,通過各種方法的調用。否則 你無法直接通過變量轉化。
比如,現在int要轉為String
-
int a=0;
-
String result=Integer.toString(a);
-
在java中包裝類,比較多的用途是用在於各種數據類型的轉化中。
我寫幾個demo
//通過包裝類來實現轉化的
-
int num=Integer.valueOf("12");
-
int num2=Integer.parseInt("12");
-
double num3=Double.valueOf("12.2");
-
double num4=Double.parseDouble("12.2");
-
//其他的類似。通過基本數據類型的包裝來的valueOf和parseXX來實現String轉為XX
-
String a=String.valueOf("1234");//這里括號中幾乎可以是任何類型
-
String b=String.valueOf(true);
-
String c=new Integer(12).toString();//通過包裝類的toString()也可以
-
String d=new Double(2.3).toString();
-
再舉例下。比如我現在要用泛型
-
List<Integer> nums;
-
這里<>需要類。如果你用int。它會報錯的。
重載和重寫的區別
override(重寫)
1. 方法名、參數、返回值相同。
2. 子類方法不能縮小父類方法的訪問權限。
3. 子類方法不能拋出比父類方法更多的異常(但子類方法可以不拋出異常)。
4. 存在於父類和子類之間。
5. 方法被定義為final不能被重寫。
overload(重載)
1. 參數類型、個數、順序至少有一個不相同。
2. 不能重載只有返回值不同的方法名。
3. 存在於父類和子類、同類中。
抽象類和接口有什么區別
接口是公開的,里面不能有私有的方法或變量,是用於讓別人使用的,而抽象類是可以有私有方法或私有變量的,
另外,實現接口的一定要實現接口里定義的所有方法,而實現抽象類可以有選擇地重寫需要用到的方法,一般的應用里,最頂級的是接口,然后是抽象類實現接口,最后才到具體類實現。
還有,接口可以實現多重繼承,而一個類只能繼承一個超類,但可以通過繼承多個接口實現多重繼承,接口還有標識(里面沒有任何方法,如Remote接口)和數據共享(里面的變量全是常量)的作用。
說說反射的用途及實現
Java反射機制主要提供了以下功能:在運行時構造一個類的對象;判斷一個類所具有的成員變量和方法;調用一個對象的方法;生成動態代理。反射最大的應用就是框架
Java反射的主要功能:
- 確定一個對象的類
- 取出類的modifiers,數據成員,方法,構造器,和超類.
- 找出某個接口里定義的常量和方法說明.
- 創建一個類實例,這個實例在運行時刻才有名字(運行時間才生成的對象).
- 取得和設定對象數據成員的值,如果數據成員名是運行時刻確定的也能做到.
- 在運行時刻調用動態對象的方法.
- 創建數組,數組大小和類型在運行時刻才確定,也能更改數組成員的值.
反射的應用很多,很多框架都有用到
spring 的 ioc/di 也是反射….
javaBean和jsp之間調用也是反射….
struts的 FormBean 和頁面之間…也是通過反射調用….
JDBC 的 classForName()也是反射…..
hibernate的 find(Class clazz) 也是反射….
反射還有一個不得不說的問題,就是性能問題,大量使用反射系統性能大打折扣。怎么使用使你的系統達到最優就看你系統架構和綜合使用問題啦,這里就不多說了。
來源:http://uule.iteye.com/blog/1423512
說說自定義注解的場景及實現
(此題自由發揮,就看你對注解的理解了!==)登陸、權限攔截、日志處理,以及各種Java框架,如Spring,Hibernate,JUnit 提到注解就不能不說反射,Java自定義注解是通過運行時靠反射獲取注解。實際開發中,例如我們要獲取某個方法的調用日志,可以通過AOP(動態代理機制)給方法添加切面,通過反射來獲取方法包含的注解,如果包含日志注解,就進行日志記錄。
HTTP 請求的 GET 與 POST 方式的區別
GET方法會把名值對追加在請求的URL后面。因為URL對字符數目有限制,進而限制了用在客戶端請求的參數值的數目。並且請求中的參數值是可見的,因此,敏感信息不能用這種方式傳遞。
POST方法通過把請求參數值放在請求體中來克服GET方法的限制,因此,可以發送的參數的數目是沒有限制的。最后,通過POST請求傳遞的敏感信息對外部客戶端是不可見的。
參考:https://www.cnblogs.com/wangli-66/p/5453507.html
session 與 cookie 區別
cookie 是 Web 服務器發送給瀏覽器的一塊信息。瀏覽器會在本地文件中給每一個 Web 服務
器存儲 cookie。以后瀏覽器在給特定的 Web 服務器發請求的時候,同時會發送所有為該服
務器存儲的 cookie。下面列出了 session 和 cookie 的區別:
無論客戶端瀏覽器做怎么樣的設置,session都應該能正常工作。客戶端可以選擇禁用 cookie,
但是, session 仍然是能夠工作的,因為客戶端無法禁用服務端的 session。
JDBC 流程
1、 加載JDBC驅動程序:
在連接數據庫之前,首先要加載想要連接的數據庫的驅動到JVM(Java虛擬機),
這通過java.lang.Class類的靜態方法forName(String className)實現。
例如:
-
try{
-
//加載MySql的驅動類
-
Class.forName("com.mysql.jdbc.Driver") ;
-
}catch(ClassNotFoundException e){
-
System.out.println("找不到驅動程序類 ,加載驅動失敗!");
-
e.printStackTrace() ;
-
}
-
成功加載后,會將Driver類的實例注冊到DriverManager類中。
2、 提供JDBC連接的URL
- 連接URL定義了連接數據庫時的協議、子協議、數據源標識。
- 書寫形式:協議:子協議:數據源標識
協議:在JDBC中總是以jdbc開始 子協議:是橋連接的驅動程序或是數據庫管理系統名稱。
數據源標識:標記找到數據庫來源的地址與連接端口。
例如:
jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=gbk;useUnicode=true;(MySql的連接URL)
表示使用Unicode字符集。如果characterEncoding設置為 gb2312或GBK,本參數必須設置為true 。characterEncoding=gbk:字符編碼方式。
3、創建數據庫的連接
- 要連接數據庫,需要向java.sql.DriverManager請求並獲得Connection對象, 該對象就代表一個數據庫的連接。
- 使用DriverManager的getConnectin(String url , String username , String password )方法傳入指定的欲連接的數據庫的路徑、數據庫的用戶名和 密碼來獲得。
例如: //連接MySql數據庫,用戶名和密碼都是root
-
String url = "jdbc:mysql://localhost:3306/test" ;
-
String username = "root" ;
-
String password = "root" ;
-
try{
-
Connection con = DriverManager.getConnection(url , username , password ) ;
-
}catch(SQLException se){
-
System.out.println("數據庫連接失敗!");
-
se.printStackTrace() ;
-
}
-
4、 創建一個Statement
•要執行SQL語句,必須獲得java.sql.Statement實例,Statement實例分為以下3 種類型:
1、執行靜態SQL語句。通常通過Statement實例實現。
2、執行動態SQL語句。通常通過PreparedStatement實例實現。
3、執行數據庫存儲過程。通常通過CallableStatement實例實現。
具體的實現方式:
Statement stmt = con.createStatement() ; PreparedStatement pstmt = con.prepareStatement(sql) ; CallableStatement cstmt = con.prepareCall(“{CALL demoSp(? , ?)}”) ;
5、執行SQL語句
Statement接口提供了三種執行SQL語句的方法:executeQuery 、executeUpdate 和execute
1、ResultSet executeQuery(String sqlString):執行查詢數據庫的SQL語句 ,返回一個結果集(ResultSet)對象。
2、int executeUpdate(String sqlString):用於執行INSERT、UPDATE或 DELETE語句以及SQL DDL語句,如:CREATE TABLE和DROP TABLE等
3、execute(sqlString):用於執行返回多個結果集、多個更新計數或二者組合的 語句。 具體實現的代碼:
ResultSet rs = stmt.executeQuery(“SELECT * FROM …”) ; int rows = stmt.executeUpdate(“INSERT INTO …”) ; boolean flag = stmt.execute(String sql) ;
6、處理結果
兩種情況:
1、執行更新返回的是本次操作影響到的記錄數。
2、執行查詢返回的結果是一個ResultSet對象。
• ResultSet包含符合SQL語句中條件的所有行,並且它通過一套get方法提供了對這些 行中數據的訪問。
• 使用結果集(ResultSet)對象的訪問方法獲取數據:
while(rs.next()){
String name = rs.getString(“name”) ;
String pass = rs.getString(1) ; // 此方法比較高效
}
(列是從左到右編號的,並且從列1開始)
7、關閉JDBC對象
操作完成以后要把所有使用的JDBC對象全都關閉,以釋放JDBC資源,關閉順序和聲 明順序相反:
1、關閉記錄集
2、關閉聲明
3、關閉連接對象
-
if(rs != null){ // 關閉記錄集
-
try{
-
rs.close() ;
-
}catch(SQLException e){
-
e.printStackTrace() ;
-
}
-
}
-
if(stmt != null){ // 關閉聲明
-
try{
-
stmt.close() ;
-
}catch(SQLException e){
-
e.printStackTrace() ;
-
}
-
}
-
if(conn != null){ // 關閉連接對象
-
try{
-
conn.close() ;
-
}catch(SQLException e){
-
e.printStackTrace() ;
-
}
-
}
-
MVC 設計思想
MVC就是
M:Model 模型
V:View 視圖
C:Controller 控制器
模型就是封裝業務邏輯和數據的一個一個的模塊,控制器就是調用這些模塊的(java中通常是用Servlet來實現,框架的話很多是用Struts2來實現這一層),視圖就主要是你看到的,比如JSP等.
當用戶發出請求的時候,控制器根據請求來選擇要處理的業務邏輯和要選擇的數據,再返回去把結果輸出到視圖層,這里可能是進行重定向或轉發等.
equals 與 == 的區別
值類型(int,char,long,boolean等)都是用==判斷相等性。對象引用的話,==判斷引用所指的對象是否是同一個。equals是Object的成員函數,有些類會覆蓋(override)這個方法,用於判斷對象的等價性。例如String類,兩個引用所指向的String都是”abc”,但可能出現他們實際對應的對象並不是同一個(和jvm實現方式有關),因此用==判斷他們可能不相等,但用equals判斷一定是相等的。
集合
List 和 Set 區別
List,Set都是繼承自Collection接口
List特點:元素有放入順序,元素可重復
Set特點:元素無放入順序,元素不可重復,重復元素會覆蓋掉
(注意:元素雖然無放入順序,但是元素在set中的位置是有該元素的HashCode決定的,其位置其實是固定的,加入Set 的Object必須定義equals()方法 ,另外list支持for循環,也就是通過下標來遍歷,也可以用迭代器,但是set只能用迭代,因為他無序,無法用下標來取得想要的值。)
Set和List對比:
Set:檢索元素效率低下,刪除和插入效率高,插入和刪除不會引起元素位置改變。
List:和數組類似,List可以動態增長,查找元素效率高,插入刪除元素效率低,因為會引起其他元素位置改變。
List 和 Map 區別
List是對象集合,允許對象重復。
Map是鍵值對的集合,不允許key重復。
Arraylist 與 LinkedList 區別
Arraylist:
優點:ArrayList是實現了基於動態數組的數據結構,因為地址連續,一旦數據存儲好了,查詢操作效率會比較高(在內存里是連着放的)。
缺點:因為地址連續, ArrayList要移動數據,所以插入和刪除操作效率比較低。
LinkedList:
優點:LinkedList基於鏈表的數據結構,地址是任意的,所以在開辟內存空間的時候不需要等一個連續的地址,對於新增和刪除操作add和remove,LinedList比較占優勢。LinkedList 適用於要頭尾操作或插入指定位置的場景
缺點:因為LinkedList要移動指針,所以查詢操作性能比較低。
適用場景分析:
當需要對數據進行對此訪問的情況下選用ArrayList,當需要對數據進行多次增加刪除修改時采用LinkedList。
ArrayList 與 Vector 區別
-
public ArrayList(int initialCapacity)//構造一個具有指定初始容量的空列表。
-
public ArrayList()//構造一個初始容量為10的空列表。
-
public ArrayList(Collection<? extends E> c)//構造一個包含指定 collection 的元素的列表
-
Vector有四個構造方法:
-
public Vector()//使用指定的初始容量和等於零的容量增量構造一個空向量。
-
public Vector(int initialCapacity)//構造一個空向量,使其內部數據數組的大小,其標准容量增量為零。
-
public Vector(Collection<? extends E> c)//構造一個包含指定 collection 中的元素的向量
-
public Vector(int initialCapacity,int capacityIncrement)//使用指定的初始容量和容量增量構造一個空的向量
-
ArrayList和Vector都是用數組實現的,主要有這么三個區別:
-
Vector是多線程安全的,線程安全就是說多線程訪問同一代碼,不會產生不確定的結果。而ArrayList不是,這個可以從源碼中看出,Vector類中的方法很多有synchronized進行修飾,這樣就導致了Vector在效率上無法與ArrayList相比;
-
兩個都是采用的線性連續空間存儲元素,但是當空間不足的時候,兩個類的增加方式是不同。
-
Vector可以設置增長因子,而ArrayList不可以。
-
Vector是一種老的動態數組,是線程同步的,效率很低,一般不贊成使用。
適用場景分析:
-
Vector是線程同步的,所以它也是線程安全的,而ArrayList是線程異步的,是不安全的。如果不考慮到線程的安全因素,一般用ArrayList效率比較高。
-
如果集合中的元素的數目大於目前集合數組的長度時,在集合中使用數據量比較大的數據,用Vector有一定的優勢。
HashMap 和 Hashtable 的區別
1.hashMap去掉了HashTable 的contains方法,但是加上了containsValue()和containsKey()方法。
2.hashTable同步的,而HashMap是非同步的,效率上逼hashTable要高。
3.hashMap允許空鍵值,而hashTable不允許。
注意:
TreeMap:非線程安全基於紅黑樹實現。TreeMap沒有調優選項,因為該樹總處於平衡狀態。
Treemap:適用於按自然順序或自定義順序遍歷鍵(key)。
參考:http://blog.csdn.net/qq_22118507/article/details/51576319
HashSet 和 HashMap 區別
set是線性結構,set中的值不能重復,hashset是set的hash實現,hashset中值不能重復是用hashmap的key來實現的。
map是鍵值對映射,可以空鍵空值。HashMap是Map接口的hash實現,key的唯一性是通過key值hash值的唯一來確定,value值是則是鏈表結構。
他們的共同點都是hash算法實現的唯一性,他們都不能持有基本類型,只能持有對象
HashMap 和 ConcurrentHashMap 的區別
ConcurrentHashMap是線程安全的HashMap的實現。
(1)ConcurrentHashMap對整個桶數組進行了分割分段(Segment),然后在每一個分段上都用lock鎖進行保護,相對於HashTable的syn關鍵字鎖的粒度更精細了一些,並發性能更好,而HashMap沒有鎖機制,不是線程安全的。
(2)HashMap的鍵值對允許有null,但是ConCurrentHashMap都不允許。
HashMap 的工作原理及代碼實現
參考:https://tracylihui.github.io/2015/07/01/Java集合學習1:HashMap的實現原理/
ConcurrentHashMap 的工作原理及代碼實現
HashTable里使用的是synchronized關鍵字,這其實是對對象加鎖,鎖住的都是對象整體,當Hashtable的大小增加到一定的時候,性能會急劇下降,因為迭代時需要被鎖定很長的時間。
ConcurrentHashMap算是對上述問題的優化,其構造函數如下,默認傳入的是16,0.75,16。
-
public ConcurrentHashMap(int paramInt1, float paramFloat, int paramInt2) {
-
//…
-
int i = 0;
-
int j = 1;
-
while (j < paramInt2) {
-
++i;
-
j <<= 1;
-
}
-
this.segmentShift = (32 - i);
-
this.segmentMask = (j - 1);
-
this.segments = Segment.newArray(j);
-
//…
-
int k = paramInt1 / j;
-
if (k * j < paramInt1)
-
++k;
-
int l = 1;
-
while (l < k)
-
l <<= 1;
-
-
for (int i1 = 0; i1 < this.segments.length; ++i1)
-
this.segments[i1] = new Segment(l, paramFloat);
-
}
-
public V put(K paramK, V paramV) {
-
if (paramV == null)
-
throw new NullPointerException();
-
int i = hash(paramK.hashCode()); //這里的hash函數和HashMap中的不一樣
-
return this.segments[(i >>> this.segmentShift & this.segmentMask)].put(paramK, i, paramV, false);
-
}
-
ConcurrentHashMap引入了分割(Segment),上面代碼中的最后一行其實就可以理解為把一個大的Map拆分成N個小的HashTable,在put方法中,會根據hash(paramK.hashCode())來決定具體存放進哪個Segment,如果查看Segment的put操作,我們會發現內部使用的同步機制是基於lock操作的,這樣就可以對Map的一部分(Segment)進行上鎖,這樣影響的只是將要放入同一個Segment的元素的put操作,保證同步的時候,鎖住的不是整個Map(HashTable就是這么做的),相對於HashTable提高了多線程環境下的性能,因此HashTable已經被淘汰了。
線程
創建線程的方式及實現
Java中創建線程主要有三種方式:
一、繼承Thread類創建線程類
(1)定義Thread類的子類,並重寫該類的run方法,該run方法的方法體就代表了線程要完成的任務。因此把run()方法稱為執行體。
(2)創建Thread子類的實例,即創建了線程對象。
(3)調用線程對象的start()方法來啟動該線程。
-
package com.thread;
-
-
public class FirstThreadTest extends Thread{
-
int i = 0;
-
//重寫run方法,run方法的方法體就是現場執行體
-
public void run()
-
{
-
for(;i<100;i++){
-
System.out.println(getName()+" "+i);
-
}
-
}
-
public static void main(String[] args)
-
{
-
for(int i = 0;i< 100;i++)
-
{
-
System.out.println(Thread.currentThread().getName()+" : "+i);
-
if(i==20)
-
{
-
new FirstThreadTest().start();
-
new FirstThreadTest().start();
-
}
-
}
-
}
-
}
-
上述代碼中Thread.currentThread()方法返回當前正在執行的線程對象。getName()方法返回調用該方法的線程的名字。
二、通過Runnable接口創建線程類
(1)定義runnable接口的實現類,並重寫該接口的run()方法,該run()方法的方法體同樣是該線程的線程執行體。
(2)創建 Runnable實現類的實例,並依此實例作為Thread的target來創建Thread對象,該Thread對象才是真正的線程對象。
(3)調用線程對象的start()方法來啟動該線程。
-
package com.thread;
-
-
public class RunnableThreadTest implements Runnable
-
{
-
-
private int i;
-
public void run()
-
{
-
for(i = 0;i <100;i++)
-
{
-
System.out.println(Thread.currentThread().getName()+" "+i);
-
}
-
}
-
public static void main(String[] args)
-
{
-
for(int i = 0;i < 100;i++)
-
{
-
System.out.println(Thread.currentThread().getName()+" "+i);
-
if(i==20)
-
{
-
RunnableThreadTest rtt = new RunnableThreadTest();
-
new Thread(rtt,"新線程1").start();
-
new Thread(rtt,"新線程2").start();
-
}
-
}
-
}
-
}
-
三、通過Callable和Future創建線程
(1)創建Callable接口的實現類,並實現call()方法,該call()方法將作為線程執行體,並且有返回值。
(2)創建Callable實現類的實例,使用FutureTask類來包裝Callable對象,該FutureTask對象封裝了該Callable對象的call()方法的返回值。
(3)使用FutureTask對象作為Thread對象的target創建並啟動新線程。
(4)調用FutureTask對象的get()方法來獲得子線程執行結束后的返回值
-
package com.thread;
-
-
import java.util.concurrent.Callable;
-
import java.util.concurrent.ExecutionException;
-
import java.util.concurrent.FutureTask;
-
-
public class CallableThreadTest implements Callable<Integer>
-
{
-
public static void main(String[] args)
-
{
-
CallableThreadTest ctt = new CallableThreadTest();
-
FutureTask<Integer> ft = new FutureTask<>(ctt);
-
for(int i = 0;i < 100;i++)
-
{
-
System.out.println(Thread.currentThread().getName()+" 的循環變量i的值"+i);
-
if(i==20)
-
{
-
new Thread(ft,"有返回值的線程").start();
-
}
-
}
-
try
-
{
-
System.out.println("子線程的返回值:"+ft.get());
-
} catch (InterruptedException e)
-
{
-
e.printStackTrace();
-
} catch (ExecutionException e)
-
{
-
e.printStackTrace();
-
}
-
}
-
-
public Integer call() throws Exception
-
{
-
int i = 0;
-
for(;i<100;i++)
-
{
-
System.out.println(Thread.currentThread().getName()+" "+i);
-
}
-
return i;
-
}
-
}
-
創建線程的三種方式的對比
采用實現Runnable、Callable接口的方式創見多線程時,優勢是:
線程類只是實現了Runnable接口或Callable接口,還可以繼承其他類。
在這種方式下,多個線程可以共享同一個target對象,所以非常適合多個相同線程來處理同一份資源的情況,從而可以將CPU、代碼和數據分開,形成清晰的模型,較好地體現了面向對象的思想。
劣勢是:
編程稍微復雜,如果要訪問當前線程,則必須使用Thread.currentThread()方法。
使用繼承Thread類的方式創建多線程時優勢是:
編寫簡單,如果需要訪問當前線程,則無需使用Thread.currentThread()方法,直接使用this即可獲得當前線程。
劣勢是:
線程類已經繼承了Thread類,所以不能再繼承其他父類。
sleep() 、join()、yield()有什么區別
1、sleep()方法
在指定的毫秒數內讓當前正在執行的線程休眠(暫停執行),此操作受到系統計時器和調度程序精度和准確性的影響。 讓其他線程有機會繼續執行,但它並不釋放對象鎖。也就是如果有Synchronized同步塊,其他線程仍然不能訪問共享數據。注意該方法要捕獲異常
比如有兩個線程同時執行(沒有Synchronized),一個線程優先級為MAX_PRIORITY,另一個為MIN_PRIORITY,如果沒有Sleep()方法,只有高優先級的線程執行完成后,低優先級的線程才能執行;但當高優先級的線程sleep(5000)后,低優先級就有機會執行了。
總之,sleep()可以使低優先級的線程得到執行的機會,當然也可以讓同優先級、高優先級的線程有執行的機會。
2、yield()方法
yield()方法和sleep()方法類似,也不會釋放“鎖標志”,區別在於,它沒有參數,即yield()方法只是使當前線程重新回到可執行狀態,所以執行yield()的線程有可能在進入到可執行狀態后馬上又被執行,另外yield()方法只能使同優先級或者高優先級的線程得到執行機會,這也和sleep()方法不同。
3、join()方法
Thread的非靜態方法join()讓一個線程B“加入”到另外一個線程A的尾部。在A執行完畢之前,B不能工作。
Thread t = new MyThread(); t.start(); t.join();
保證當前線程停止執行,直到該線程所加入的線程完成為止。然而,如果它加入的線程沒有存活,則當前線程不需要停止。
說說 CountDownLatch 原理
參考:
Java並發編程:CountDownLatch、CyclicBarrier和Semaphore
說說 CyclicBarrier 原理
參考:
說說 Semaphore 原理
說說 Exchanger 原理
java.util.concurrent.Exchanger應用范例與原理淺析
說說 CountDownLatch 與 CyclicBarrier 區別
盡量把CyclicBarrier和CountDownLatch的區別說通俗點
ThreadLocal 原理分析
講講線程池的實現原理
主要是ThreadPoolExecutor的實現原理
線程池的幾種方式
newFixedThreadPool(int nThreads)
創建一個固定長度的線程池,每當提交一個任務就創建一個線程,直到達到線程池的最大數量,這時線程規模將不再變化,當線程發生未預期的錯誤而結束時,線程池會補充一個新的線程
newCachedThreadPool()
創建一個可緩存的線程池,如果線程池的規模超過了處理需求,將自動回收空閑線程,而當需求增加時,則可以自動添加新線程,線程池的規模不存在任何限制
newSingleThreadExecutor()
這是一個單線程的Executor,它創建單個工作線程來執行任務,如果這個線程異常結束,會創建一個新的來替代它;它的特點是能確保依照任務在隊列中的順序來串行執行
newScheduledThreadPool(int corePoolSize)
創建了一個固定長度的線程池,而且以延遲或定時的方式來執行任務,類似於Timer。
舉個栗子
-
private static final Executor exec=Executors.newFixedThreadPool(50);
-
-
Runnable runnable=new Runnable(){
-
public void run(){
-
...
-
}
-
}
-
exec.execute(runnable);
-
-
Callable<Object> callable=new Callable<Object>() {
-
public Object call() throws Exception {
-
return null;
-
}
-
};
-
-
Future future=executorService.submit(callable);
-
future.get(); // 等待計算完成后,獲取結果
-
future.isDone(); // 如果任務已完成,則返回 true
-
future.isCancelled(); // 如果在任務正常完成前將其取消,則返回 true
-
future.cancel(true); // 試圖取消對此任務的執行,true中斷運行的任務,false允許正在運行的任務運行完成
-
參考:
線程的生命周期
新建(New)、就緒(Runnable)、運行(Running)、阻塞(Blocked)和死亡(Dead)5種狀態
(1)生命周期的五種狀態
新建(new Thread)
當創建Thread類的一個實例(對象)時,此線程進入新建狀態(未被啟動)。
例如:Thread t1=new Thread();
就緒(runnable)
線程已經被啟動,正在等待被分配給CPU時間片,也就是說此時線程正在就緒隊列中排隊等候得到CPU資源。例如:t1.start();
運行(running)
線程獲得CPU資源正在執行任務(run()方法),此時除非此線程自動放棄CPU資源或者有優先級更高的線程進入,線程將一直運行到結束。
死亡(dead)
當線程執行完畢或被其它線程殺死,線程就進入死亡狀態,這時線程不可能再進入就緒狀態等待執行。
自然終止:正常運行run()方法后終止
異常終止:調用stop()方法讓一個線程終止運行
堵塞(blocked)
由於某種原因導致正在運行的線程讓出CPU並暫停自己的執行,即進入堵塞狀態。
正在睡眠:用sleep(long t) 方法可使線程進入睡眠方式。一個睡眠着的線程在指定的時間過去可進入就緒狀態。
正在等待:調用wait()方法。(調用motify()方法回到就緒狀態)
被另一個線程所阻塞:調用suspend()方法。(調用resume()方法恢復)
參考:
鎖機制
說說線程安全問題
線程安全是指要控制多個線程對某個資源的有序訪問或修改,而在這些線程之間沒有產生沖突。
在Java里,線程安全一般體現在兩個方面:
1、多個thread對同一個java實例的訪問(read和modify)不會相互干擾,它主要體現在關鍵字synchronized。如ArrayList和Vector,HashMap和Hashtable(后者每個方法前都有synchronized關鍵字)。如果你在interator一個List對象時,其它線程remove一個element,問題就出現了。
2、每個線程都有自己的字段,而不會在多個線程之間共享。它主要體現在java.lang.ThreadLocal類,而沒有Java關鍵字支持,如像static、transient那樣。
volatile 實現原理
悲觀鎖 樂觀鎖
樂觀鎖 悲觀鎖
是一種思想。可以用在很多方面。
比如數據庫方面。
悲觀鎖就是for update(鎖定查詢的行)
樂觀鎖就是 version字段(比較跟上一次的版本號,如果一樣則更新,如果失敗則要重復讀-比較-寫的操作。)
JDK方面:
悲觀鎖就是sync
樂觀鎖就是原子類(內部使用CAS實現)
本質來說,就是悲觀鎖認為總會有人搶我的。
樂觀鎖就認為,基本沒人搶。
CAS 樂觀鎖
樂觀鎖是一種思想,即認為讀多寫少,遇到並發寫的可能性比較低,所以采取在寫時先讀出當前版本號,然后加鎖操作(比較跟上一次的版本號,如果一樣則更新),如果失敗則要重復讀-比較-寫的操作。
CAS是一種更新的原子操作,比較當前值跟傳入值是否一樣,一樣則更新,否則失敗。
CAS頂多算是樂觀鎖寫那一步操作的一種實現方式罷了,不用CAS自己加鎖也是可以的。
ABA 問題
ABA:如果另一個線程修改V值假設原來是A,先修改成B,再修改回成A,當前線程的CAS操作無法分辨當前V值是否發生過變化。
參考:
樂觀鎖的業務場景及實現方式
樂觀鎖(Optimistic Lock):
每次獲取數據的時候,都不會擔心數據被修改,所以每次獲取數據的時候都不會進行加鎖,但是在更新數據的時候需要判斷該數據是否被別人修改過。如果數據被其他線程修改,則不進行數據更新,如果數據沒有被其他線程修改,則進行數據更新。由於數據沒有進行加鎖,期間該數據可以被其他線程進行讀寫操作。
樂觀鎖:比較適合讀取操作比較頻繁的場景,如果出現大量的寫入操作,數據發生沖突的可能性就會增大,為了保證數據的一致性,應用層需要不斷的重新獲取數據,這樣會增加大量的查詢操作,降低了系統的吞吐量。
核心篇
數據存儲
MySQL 索引使用的注意事項
參考:
說說反模式設計
參考:
說說分庫與分表設計
分庫與分表帶來的分布式困境與應對之策
服務端指南 數據存儲篇 | MySQL(09) 分庫與分表帶來的分布式困境與應對之策
說說 SQL 優化之道
MySQL 遇到的死鎖問題
參考:
存儲引擎的 InnoDB 與 MyISAM
1)InnoDB支持事務,MyISAM不支持,這一點是非常之重要。事務是一種高級的處理方式,如在一些列增刪改中只要哪個出錯還可以回滾還原,而MyISAM就不可以了。
2)MyISAM適合查詢以及插入為主的應用,InnoDB適合頻繁修改以及涉及到安全性較高的應用
3)InnoDB支持外鍵,MyISAM不支持
4)從MySQL5.5.5以后,InnoDB是默認引擎
5)InnoDB不支持FULLTEXT類型的索引
6)InnoDB中不保存表的行數,如select count() from table時,InnoDB需要掃描一遍整個表來計算有多少行,但是MyISAM只要簡單的讀出保存好的行數即可。注意的是,當count()語句包含where條件時MyISAM也需要掃描整個表
7)對於自增長的字段,InnoDB中必須包含只有該字段的索引,但是在MyISAM表中可以和其他字段一起建立聯合索引
8)清空整個表時,InnoDB是一行一行的刪除,效率非常慢。MyISAM則會重建表
9)InnoDB支持行鎖(某些情況下還是鎖整表,如 update table set a=1 where user like ‘%lee%’
參考:
數據庫索引的原理
參考:
http://blog.csdn.net/suifeng3051/article/details/52669644
為什么要用 B-tree
鑒於B-tree具有良好的定位特性,其常被用於對檢索時間要求苛刻的場合,例如:
1、B-tree索引是數據庫中存取和查找文件(稱為記錄或鍵值)的一種方法。
2、硬盤中的結點也是B-tree結構的。與內存相比,硬盤必須花成倍的時間來存取一個數據元素,這是因為硬盤的機械部件讀寫數據的速度遠遠趕不上純電子媒體的內存。與一個結點兩個分支的二元樹相比,B-tree利用多個分支(稱為子樹)的結點,減少獲取記錄時所經歷的結點數,從而達到節省存取時間的目的。
聚集索引與非聚集索引的區別
參考:
limit 20000 加載很慢怎么解決
LIMIT n 等價於 LIMIT 0,n
此題總結一下就是讓limit走索引去查詢,例如:order by 索引字段
,或者limit前面根where條件走索引字段等等。
參考:
選擇合適的分布式主鍵方案
參考:
選擇合適的數據存儲方案
- 關系型數據庫 MySQL
MySQL 是一個最流行的關系型數據庫,在互聯網產品中應用比較廣泛。一般情況下,MySQL 數據庫是選擇的第一方案,基本上有 80% ~ 90% 的場景都是基於 MySQL 數據庫的。因為,需要關系型數據庫進行管理,此外,業務存在許多事務性的操作,需要保證事務的強一致性。同時,可能還存在一些復雜的 SQL 的查詢。值得注意的是,前期盡量減少表的聯合查詢,便於后期數據量增大的情況下,做數據庫的分庫分表。
- 內存數據庫 Redis
隨着數據量的增長,MySQL 已經滿足不了大型互聯網類應用的需求。因此,Redis 基於內存存儲數據,可以極大的提高查詢性能,對產品在架構上很好的補充。例如,為了提高服務端接口的訪問速度,盡可能將讀頻率高的熱點數據存放在 Redis 中。這個是非常典型的以空間換時間的策略,使用更多的內存換取 CPU 資源,通過增加系統的內存消耗,來加快程序的運行速度。
在某些場景下,可以充分的利用 Redis 的特性,大大提高效率。這些場景包括緩存,會話緩存,時效性,訪問頻率,計數器,社交列表,記錄用戶判定信息,交集、並集和差集,熱門列表與排行榜,最新動態等。
使用 Redis 做緩存的時候,需要考慮數據不一致與臟讀、緩存更新機制、緩存可用性、緩存服務降級、緩存穿透、緩存預熱等緩存使用問題。
- 文檔數據庫 MongoDB
MongoDB 是對傳統關系型數據庫的補充,它非常適合高伸縮性的場景,它是可擴展性的表結構。基於這點,可以將預期范圍內,表結構可能會不斷擴展的 MySQL 表結構,通過 MongoDB 來存儲,這就可以保證表結構的擴展性。
此外,日志系統數據量特別大,如果用 MongoDB 數據庫存儲這些數據,利用分片集群支持海量數據,同時使用聚集分析和 MapReduce 的能力,是個很好的選擇。
MongoDB 還適合存儲大尺寸的數據,GridFS 存儲方案就是基於 MongoDB 的分布式文件存儲系統。
- 列族數據庫 HBase
HBase 適合海量數據的存儲與高性能實時查詢,它是運行於 HDFS 文件系統之上,並且作為 MapReduce 分布式處理的目標數據庫,以支撐離線分析型應用。在數據倉庫、數據集市、商業智能等領域發揮了越來越多的作用,在數以千計的企業中支撐着大量的大數據分析場景的應用。
- 全文搜索引擎 ElasticSearch
在一般情況下,關系型數據庫的模糊查詢,都是通過 like 的方式進行查詢。其中,like “value%” 可以使用索引,但是對於 like “%value%” 這樣的方式,執行全表查詢,這在數據量小的表,不存在性能問題,但是對於海量數據,全表掃描是非常可怕的事情。ElasticSearch 作為一個建立在全文搜索引擎 Apache Lucene 基礎上的實時的分布式搜索和分析引擎,適用於處理實時搜索應用場景。此外,使用 ElasticSearch 全文搜索引擎,還可以支持多詞條查詢、匹配度與權重、自動聯想、拼寫糾錯等高級功能。因此,可以使用 ElasticSearch 作為關系型數據庫全文搜索的功能補充,將要進行全文搜索的數據緩存一份到 ElasticSearch 上,達到處理復雜的業務與提高查詢速度的目的。
ElasticSearch 不僅僅適用於搜索場景,還非常適合日志處理與分析的場景。著名的 ELK 日志處理方案,由 ElasticSearch、Logstash 和 Kibana 三個組件組成,包括了日志收集、聚合、多維度查詢、可視化顯示等。
ObjectId 規則
參考:
聊聊 MongoDB 使用場景
參考:
倒排索引
參考:
聊聊 ElasticSearch 使用場景
在一般情況下,關系型數據庫的模糊查詢,都是通過 like 的方式進行查詢。其中,like “value%” 可以使用索引,但是對於 like “%value%” 這樣的方式,執行全表查詢,這在數據量小的表,不存在性能問題,但是對於海量數據,全表掃描是非常可怕的事情。ElasticSearch 作為一個建立在全文搜索引擎 Apache Lucene 基礎上的實時的分布式搜索和分析引擎,適用於處理實時搜索應用場景。此外,使用 ElasticSearch 全文搜索引擎,還可以支持多詞條查詢、匹配度與權重、自動聯想、拼寫糾錯等高級功能。因此,可以使用 ElasticSearch 作為關系型數據庫全文搜索的功能補充,將要進行全文搜索的數據緩存一份到 ElasticSearch 上,達到處理復雜的業務與提高查詢速度的目的。
緩存使用
Redis 有哪些類型
Redis支持五種數據類型:string(字符串),hash(哈希),list(列表),set(集合)及zset(sorted set:有序集合)。
參考:
Redis 數據類型
Redis 內部結構
參考:
聊聊 Redis 使用場景
隨着數據量的增長,MySQL 已經滿足不了大型互聯網類應用的需求。因此,Redis 基於內存存儲數據,可以極大的提高查詢性能,對產品在架構上很好的補充。例如,為了提高服務端接口的訪問速度,盡可能將讀頻率高的熱點數據存放在 Redis 中。這個是非常典型的以空間換時間的策略,使用更多的內存換取 CPU 資源,通過增加系統的內存消耗,來加快程序的運行速度。
在某些場景下,可以充分的利用 Redis 的特性,大大提高效率。這些場景包括緩存,會話緩存,時效性,訪問頻率,計數器,社交列表,記錄用戶判定信息,交集、並集和差集,熱門列表與排行榜,最新動態等。
使用 Redis 做緩存的時候,需要考慮數據不一致與臟讀、緩存更新機制、緩存可用性、緩存服務降級、緩存穿透、緩存預熱等緩存使用問題。
Redis 持久化機制
參考:
Redis 如何實現持久化
參考:
Redis 集群方案與實現
參考:
Redis 為什么是單線程的
單純的網絡IO來說,量大到一定程度之后,多線程的確有優勢——但並不是單純的多線程,而是每個線程自己有自己的epoll這樣的模型,也就是多線程和multiplexing混合。
一般這個開頭我們都會跟一個“但是”。
但是。
還要考慮Redis操作的對象。它操作的對象是內存中的數據結構。如果在多線程中操作,那就需要為這些對象加鎖。最終來說,多線程性能有提高,但是每個線程的效率嚴重下降了。而且程序的邏輯嚴重復雜化。
要知道Redis的數據結構並不全是簡單的Key-Value,還有列表,hash,map等等復雜的結構,這些結構有可能會進行很細粒度的操作,比如在很長的列表后面添加一個元素,在hash當中添加或者刪除一個對象,等等。這些操作還可以合成MULTI/EXEC的組。這樣一個操作中可能就需要加非常多的鎖,導致的結果是同步開銷大大增加。這還帶來一個惡果就是吞吐量雖然增大,但是響應延遲可能會增加。
Redis在權衡之后的選擇是用單線程,突出自己功能的靈活性。在單線程基礎上任何原子操作都可以幾乎無代價地實現,多么復雜的數據結構都可以輕松運用,甚至可以使用Lua腳本這樣的功能。對於多線程來說這需要高得多的代價。
並不是所有的KV數據庫或者內存數據庫都應該用單線程,比如ZooKeeper就是多線程的,最終還是看作者自己的意願和取舍。單線程的威力實際上非常強大,每核心效率也非常高,在今天的虛擬化環境當中可以充分利用雲化環境來提高資源利用率。多線程自然是可以比單線程有更高的性能上限,但是在今天的計算環境中,即使是單機多線程的上限也往往不能滿足需要了,需要進一步摸索的是多服務器集群化的方案,這些方案中多線程的技術照樣是用不上的,所以單線程、多進程的集群不失為一個時髦的解決方案。
作者:靈劍
鏈接:https://www.zhihu.com/question/23162208/answer/142424042
來源:知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請注明出處。
緩存奔潰
參考:
緩存降級
服務降級的目的,是為了防止Redis服務故障,導致數據庫跟着一起發生雪崩問題。因此,對於不重要的緩存數據,可以采取服務降級策略,例如一個比較常見的做法就是,Redis出現問題,不去數據庫查詢,而是直接返回默認值給用戶。
使用緩存的合理性問題
參考:
消息隊列
消息隊列的使用場景
主要解決應用耦合,異步消息,流量削鋒等問題
消息的重發補償解決思路
參考:
消息的冪等性解決思路
參考:
消息的堆積解決思路
參考:
Sun Java System Message Queue 3.7 UR1 管理指南
自己如何實現消息隊列
參考:
如何保證消息的有序性
參考:
消息隊列的exclusive consumer功能是如何保證消息有序和防止腦裂的
框架篇
Spring
BeanFactory 和 ApplicationContext 有什么區別
beanfactory顧名思義,它的核心概念就是bean工廠,用作於bean生命周期的管理,而applicationcontext這個概念就比較豐富了,單看名字(應用上下文)就能看出它包含的范圍更廣,它繼承自bean factory但不僅僅是繼承自這一個接口,還有繼承了其他的接口,所以它不僅僅有bean factory相關概念,更是一個應用系統的上下文,其設計初衷應該是一個包羅萬象的對外暴露的一個綜合的API。
Spring Bean 的生命周期
參考:
Spring IOC 如何實現
參考:
說說 Spring AOP
參考:
Spring AOP 實現原理
參考:
動態代理(cglib 與 JDK)
java動態代理是利用反射機制生成一個實現代理接口的匿名類,在調用具體方法前調用InvokeHandler來處理。
而cglib動態代理是利用asm開源包,對代理對象類的class文件加載進來,通過修改其字節碼生成子類來處理。
1、如果目標對象實現了接口,默認情況下會采用JDK的動態代理實現AOP
2、如果目標對象實現了接口,可以強制使用CGLIB實現AOP
3、如果目標對象沒有實現了接口,必須采用CGLIB庫,spring會自動在JDK動態代理和CGLIB之間轉換
如何強制使用CGLIB實現AOP?
(1)添加CGLIB庫,SPRING_HOME/cglib/*.jar
(2)在spring配置文件中加入
JDK動態代理和CGLIB字節碼生成的區別?
(1)JDK動態代理只能對實現了接口的類生成代理,而不能針對類
(2)CGLIB是針對類實現代理,主要是對指定的類生成一個子類,覆蓋其中的方法
因為是繼承,所以該類或方法最好不要聲明成final
參考:
Spring 事務實現方式
參考:
Spring 事務底層原理
參考:
如何自定義注解實現功能
可以結合spring的AOP,對注解進行攔截,提取注解。
大致流程為:
1. 新建一個注解@MyLog,加在需要注解申明的方法上面
2. 新建一個類MyLogAspect,通過@Aspect注解使該類成為切面類。
3. 通過@Pointcut 指定切入點 ,這里指定的切入點為MyLog注解類型,也就是被@MyLog注解修飾的方法,進入該切入點。
4. MyLogAspect中的方法通過加通知注解(@Before、@Around、@AfterReturning、@AfterThrowing、@After等各種通知)指定要做的業務操作。
Spring MVC 運行流程
一、先用文字描述
1.用戶發送請求到DispatchServlet
2.DispatchServlet根據請求路徑查詢具體的Handler
3.HandlerMapping返回一個HandlerExcutionChain給DispatchServlet
HandlerExcutionChain:Handler和Interceptor集合
4.DispatchServlet調用HandlerAdapter適配器
5.HandlerAdapter調用具體的Handler處理業務
6.Handler處理結束返回一個具體的ModelAndView給適配器
ModelAndView:model–>數據模型,view–>視圖名稱
7.適配器將ModelAndView給DispatchServlet
8.DispatchServlet把視圖名稱給ViewResolver視圖解析器
9.ViewResolver返回一個具體的視圖給DispatchServlet
10.渲染視圖
11.展示給用戶
二、畫圖解析
SpringMvc的配置
Spring MVC 啟動流程
參考:
Spring 的單例實現原理
參考:
Spring 框架中用到了哪些設計模式
Spring框架中使用到了大量的設計模式,下面列舉了比較有代表性的:
代理模式—在AOP和remoting中被用的比較多。
單例模式—在spring配置文件中定義的bean默認為單例模式。
模板方法—用來解決代碼重復的問題。比如. RestTemplate, JmsTemplate
, JpaTemplate。
工廠模式—BeanFactory用來創建對象的實例。
適配器–spring aop
裝飾器–spring data hashmapper
觀察者– spring 時間驅動模型
回調–Spring ResourceLoaderAware回調接口
前端控制器–spring用前端控制器DispatcherServlet對請求進行分發
Spring 其他產品(Srping Boot、Spring Cloud、Spring Secuirity、Spring Data、Spring AMQP 等)
參考:
Netty
為什么選擇 Netty
Netty 是業界最流行的 NIO 框架之一,它的健壯性、功能、性能、可定制性和可擴展性在同類框架中都是首屈一指的,它已經得到成百上千的商用項目驗證,例如 Hadoop 的 RPC 框架 Avro 使用 Netty 作為通信框架。很多其它業界主流的 RPC 和分布式服務框架,也使用 Netty 來構建高性能的異步通信能力。
Netty 的優點總結如下:
- API 使用簡單,開發門檻低;
- 功能強大,預置了多種編解碼功能,支持多種主流協議;
- 定制能力強,可以通過 ChannelHandler 對通信框架進行靈活的擴展;
- 性能高,通過與其它業界主流的 NIO 框架對比,Netty 的綜合性能最優;
- 社區活躍,版本迭代周期短,發現的 BUG 可以被及時修復,同時,更多的新功能會被加入;
- 經歷了大規模的商業應用考驗,質量得到驗證。在互聯網、大數據、網絡游戲、企業應用、電信軟件等眾多行業得到成功商用,證明了它完全滿足不同行業的商用標准。
正是因為這些優點,Netty 逐漸成為 Java NIO 編程的首選框架。
說說業務中,Netty 的使用場景
原生的 NIO 在 JDK 1.7 版本存在 epoll bug
它會導致Selector空輪詢,最終導致CPU 100%。官方聲稱在JDK1.6版本的update18修復了該問題,但是直到JDK1.7版本該問題仍舊存在,只不過該BUG發生概率降低了一些而已,它並沒有被根本解決。該BUG以及與該BUG相關的問題單可以參見以下鏈接內容。
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6403933
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=2147719
異常堆棧如下:
-
java.lang.Thread.State: RUNNABLE
-
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
-
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)
-
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
-
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
-
- locked <0x0000000750928190> (a sun.nio.ch.Util$2)
-
- locked <0x00000007509281a8> (a java.util.Collections$ UnmodifiableSet)
-
- locked <0x0000000750946098> (a sun.nio.ch.EPollSelectorImpl)
-
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
-
at net.spy.memcached.MemcachedConnection.handleIO(Memcached Connection.java:217)
-
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection. java:836)
什么是TCP 粘包/拆包
參考:
TCP粘包/拆包的解決辦法
參考:
Netty 線程模型
參考:
說說 Netty 的零拷貝
參考:
Netty 內部執行流程
參考:
Netty 重連實現
參考:
微服務篇
微服務
前后端分離是如何做的
參考:
微服務哪些框架
Spring Cloud、Dubbo、Hsf等
你怎么理解 RPC 框架
RPC的目的是讓你在本地調用遠程的方法,而對你來說這個調用是透明的,你並不知道這個調用的方法是部署哪里。通過RPC能解耦服務,這才是使用RPC的真正目的。
說說 RPC 的實現原理
參考:
說說 Dubbo 的實現原理
dubbo提供功能來講, 提供基礎功能-RPC調用 提供增值功能SOA服務治理
dubbo啟動時查找可用的遠程服務提供者,調用接口時不是最終調用本地實現,而是通過攔截調用(又用上JDK動態代理功能)過程經過一系列的的序列化、遠程通信、協議解析最終調用到遠程服務提供者
參考:
你怎么理解 RESTful
REST是 一種軟件架構風格、設計風格,它是一種面向資源的網絡化超媒體應用的架構風格。它主要是用於構建輕量級的、可維護的、可伸縮的 Web 服務。基於 REST 的服務被稱為 RESTful 服務。REST 不依賴於任何協議,但是幾乎每個 RESTful 服務使用 HTTP 作為底層協議,RESTful使用http method標識操作,例如:
http://127.0.0.1/user/1 GET 根據用戶id查詢用戶數據
http://127.0.0.1/user POST 新增用戶
http://127.0.0.1/user PUT 修改用戶信息
http://127.0.0.1/user DELETE 刪除用戶信息
說說如何設計一個良好的 API
參考:
如何理解 RESTful API 的冪等性
參考:
如何保證接口的冪等性
參考:
說說 CAP 定理、 BASE 理論
參考:
怎么考慮數據一致性問題
參考:
說說最終一致性的實現方案
可以結合MQ實現最終一致性,例如電商系統,把生成訂單數據的寫操作邏輯通過事務控制,一些無關緊要的業務例如日志處理,通知,通過異步消息處理,最終到請求落地。
參考:
你怎么看待微服務
- 小:微服務體積小
- 獨:能夠獨立的部署和運行。
- 輕:使用輕量級的通信機制和架構。
- 松:為服務之間是松耦合的。
微服務與 SOA 的區別
可以把微服務當做去除了ESB的SOA。ESB是SOA架構中的中心總線,設計圖形應該是星形的,而微服務是去中心化的分布式軟件架構。
參考:
如何拆分服務
參考:
微服務如何進行數據庫管理
參考:
如何應對微服務的鏈式調用異常
參考:
對於快速追蹤與定位問題
參考:
微服務的安全
參考:
分布式
談談業務中使用分布式的場景
一、解決java集群的session共享的解決方案:
1.客戶端cookie加密。(一般用於內網中企業級的系統中,要求用戶瀏覽器端的cookie不能禁用,禁用的話,該方案會失效)。
2.集群中,各個應用服務器提供了session復制的功能,tomcat和jboss都實現了這樣的功能。特點:性能隨着服務器增加急劇下降,容易引起廣播風暴;session數據需要序列化,影響性能。
3.session的持久化,使用數據庫來保存session。就算服務器宕機也沒事兒,數據庫中的session照樣存在。特點:每次請求session都要讀寫數據庫,會帶來性能開銷。使用內存數據庫,會提高性能,但是宕機會丟失數據(像支付寶的宕機,有同城災備、異地災備)。
4.使用共享存儲來保存session。和數據庫類似,就算宕機了也沒有事兒。其實就是專門搞一台服務器,全部對session落地。特點:頻繁的進行序列化和反序列化會影響性能。
5.使用memcached來保存session。本質上是內存數據庫的解決方案。特點:存入memcached的數據需要序列化,效率極低。
二、分布式事務的解決方案:
1.TCC解決方案:try confirm cancel。
Session 分布式方案
1.客戶端cookie加密。(一般用於內網中企業級的系統中,要求用戶瀏覽器端的cookie不能禁用,禁用的話,該方案會失效)。
2.集群中,各個應用服務器提供了session復制的功能,tomcat和jboss都實現了這樣的功能。特點:性能隨着服務器增加急劇下降,容易引起廣播風暴;session數據需要序列化,影響性能。
3.session的持久化,使用數據庫來保存session。就算服務器宕機也沒事兒,數據庫中的session照樣存在。特點:每次請求session都要讀寫數據庫,會帶來性能開銷。使用內存數據庫,會提高性能,但是宕機會丟失數據(像支付寶的宕機,有同城災備、異地災備)。
4.使用共享存儲來保存session。和數據庫類似,就算宕機了也沒有事兒。其實就是專門搞一台服務器,全部對session落地。特點:頻繁的進行序列化和反序列化會影響性能。
5.使用memcached來保存session。本質上是內存數據庫的解決方案。特點:存入memcached的數據需要序列化,效率極低。
分布式鎖的場景
比如交易系統的金額修改,同一時間只能又一個人操作,比如秒殺場景,同一時間只能一個用戶搶到,比如火車站搶票等等
分布式鎖的實現方案
- 基於數據庫實現分布式鎖
- 基於緩存實現分布式鎖
- 基於Zookeeper實現分布式鎖
參考:
分布式事務
參考:
集群與負載均衡的算法與實現
參考:
說說分庫與分表設計
參考:
分庫與分表帶來的分布式困境與應對之策
參考:
服務端指南 數據存儲篇 | MySQL(09) 分庫與分表帶來的分布式困境與應對之策