1.Lambda表達式 2.Stream函數式操做流元素集合 3.接口新增:默認方法與靜態方法 4.方法引用,與Lambda表達式聯合使用 5.引入重複註解 6.類型註解 7.最新的Date/Time API (JSR 310) 8.新增base64加解密API 9.數組並行(parallel)操做 10.JVM的PermGen空間被移除:取代它的是Metaspace(JEP 122)元空間
1.字節流操做不會用到緩衝區,而字符流操做用到了緩衝區。 因此在操做文件時,好比字符流寫入,若是沒有關閉字符流,直接打開文件,發現文件是空的,由於數據還在緩存中。
那是用字符流好仍是字節流好?html
固然是字節流,全部文件在硬盤或文件都是以字節流方式進行的,而字符只有在內存中是。java
線程安全就是多線程訪問時,採用了加鎖機制,當一個線程訪問某個數據時,進行保護,其餘線程沒法訪問,只有當該線程訪問結束後,其餘線程才能訪問。不會出現數據不一致或者數據污染的狀況。mysql
實現線程安全的幾種方法:linux
synchronized:包括同步方法,同步代碼庫等;web
鎖:ReentrantLock,可重入鎖,獨佔鎖面試
原子類:atomicInteger等算法
volatile:volatile只能保證內存的可見性,若是是非原子操做沒法保證線程安全。spring
1.接口不能有方法的具體實現,而抽象類能夠有;sql
2.接口裏面方法都是抽象的,而抽象類能夠有普通方法;數據庫
3.一個類能夠實現多個接口,而只能繼承一個抽象類;
4.接口裏面的方法都爲public的,而抽象類的能夠爲私有的。
5.使用場景,接口通常用於沒有共同特性,每一個方法都須要本身去實現;而抽象類能夠有一部分公共的特性,本身去實現特有的一部分。好比Thread就是抽象類,繼承Thread的類能夠本身去實現run()方法,可是也能夠用公用的方法,好比sleep等,而Runnable則爲接口,全部實現者均須要實現run方法。
hashcode調用的實際是本地的方法,public native int hashCode(); 具體實現可能跟機器有關係了。
主要使用在hashMap,hashSet等中,一般用來判斷一個元素存儲的下班,好比一個hashMap比較大時,不可能一直調用equals來判斷是否有相同的元素。使用hashcode能直接定位到數據的下標位置;
若是x.equals(y)返回「true」,那麼x和y的hashCode()必須相等。
若是x.equals(y)返回「false」,那麼x和y的hashCode()有可能相等,也有可能不等。
erro指程序沒法處理的錯誤,通常指與虛擬機相關的錯誤,通常不須要程序處理,好比內存空間不足,棧溢出等
exception是指程序自己能夠處理的異常,好比空指針,數據越界等;
RuntimeException指程序運行時纔會出現的錯誤,在定義方法時不須要聲明可能會拋出的異常,好比nullpoint,arrayIndexOutOfBound等
非RuntimeException指在定義方法時,必須聲明可能存在的異常,不然編譯器不經過,好比IOException等。
沒用過組合,不說了
經常使用的有valueOf()等,這裏以Integer.valueOf()爲例。 靜態工廠方法的實如今另一篇博客中有介紹Java 靜態工廠方法。
優勢:
1.能夠用方法名來標識,提升程序可讀性;
2.沒必要在每次調用類時都建立一個新的對象;這裏每次獲取一個Integer類型的對象,不須要new一個Integer對象實例;
3.能夠返回原返回類型的任何子類型對象; 好比原本要返回的對象是Fruit,若是Apple集成了Fruit,直接返回Apple也是能夠的
4.代碼簡介
缺點:
1.若是沒有public或protect方法,則沒法子類化,即沒法被繼承;
2.和普通的靜態方法沒什麼區別;
這個百度搜索吧。。。
經常使用的就是GBK和UTF8
GBK文字編碼採用雙字節,不管中英文,均使用雙字節來表示;中文規範;
UTF-8英文一個字節編碼,中文三個字節編碼;國際規範;
可使用limit,好比查詢後按照分數排序,最後加上limit2,1,可是不肯定這種是否是性能最好的方式;
序列化的意義就是把數據換個時間,換個地點再次使用;
換個時間,好比在重啓服務前把內存中的對象保存到文件或者數據庫中,重啓後再次使用;
換個地點,就是網絡傳輸的場景了
SAX
sax是一個用於處理xml事件驅動的「推」模型;
優勢:解析速度快,佔用內存少,它須要哪些數據再加載和解析哪些內容。
缺點:它不會記錄標籤的關係,而是須要應用程序本身處理,這樣就會增長程序的負擔。
DOM
dom是一種文檔對象模型;
優勢:dom能夠以一種獨立於平臺和語言的方式訪問和修改一個文檔的內容和結構,dom技術使得用戶頁面能夠動態的變化,如動態顯示隱藏一個元素,改變它的屬性,增長一個元素等,dom可使頁面的交互性大大加強。
缺點:dom解析xml文件時會將xml文件的全部內容以文檔樹方式存放在內存中。
PULL
pull和sax很類似,區別在於:pull讀取xml文件後觸發相應的事件調用方法返回的是數字,且pull能夠在程序中控制,想解析到哪裏就能夠中止解析。 (SAX解析器的工做方式是自動將事件推入事件處理器進行處理,所以你不能控制事件的處理主動結束;而Pull解析器的工做方式爲容許你的應用程序代碼主動從解析器中獲取事件,正由於是主動獲取事件,所以能夠在知足了須要的條件後再也不獲取事件,結束解析。pull是一個while循環,隨時能夠跳出,而sax不是,sax是隻要解析了,就必須解析完成。)
鏈接池的原理,主要是要維護共享的池子,須要考慮到資源競爭和池子大小的問題,實現主要考慮經過信號量和鎖來實現。關閉鏈接不是銷燬鏈接,是回收鏈接。
安全和非安全
https用到證書,SSL
https加密
默認端口不同
1.OOM出現主要發生在老年代和永久代,首先查看OOM是哪一種?
heap space:堆內存溢出,通常因爲內存泄漏或堆大小設置過小致使。堆大小設置能夠經過-Xms,Xmx來設置。內存泄漏須要經過dump工具來查看代碼哪一個地方出現問題。
PermGen:永久代溢出,即方法區溢出了,這種狀況出現的可能比較少,通常因爲出現大量的class或jsp頁面,或者採用cglib反射機制致使,另外常量太多也會致使,好比string常量。通常經過調整永久代大小解決。使用相似-XX:PermSize=64m -XX:MaxPermSize=256m
stackOverFlowError;棧溢出,通常不會拋OOM,通常因爲程序有深度遞歸調用或者死循環致使,排除代碼是否有問題,以及調整棧的大小,-Xss來設置棧的大小。
OOM分析,先heapdump內存信息,再經過工具來展現
dump後須要分析,通常使用下面兩種工具,經常使用的是mat
1.反射機制:使用class的newInstance()方法/使用constructor的newInstance方法
2.序列化
3.clone
GC介紹Java GC機制
能夠看下線程池的分析Java 線程池分析
哈希表這個數據結構想必大多數人都不陌生,並且在不少地方都會利用到hash表來提升查找效率。在Java的Object類中有一個方法:
1
|
public
native
int
hashCode();
|
根據這個方法的聲明可知,該方法返回一個int類型的數值,而且是本地方法,所以在Object類中並無給出具體的實現。
爲什麼Object類須要這樣一個方法?它有什麼做用呢?今天咱們就來具體探討一下hashCode方法。
對於包含容器類型的程序設計語言來講,基本上都會涉及到hashCode。在Java中也同樣,hashCode方法的主要做用是爲了配合基於散列的集合一塊兒正常運行,這樣的散列集合包括HashSet、HashMap以及HashTable。
爲何這麼說呢?考慮一種狀況,當向集合中插入對象時,如何判別在集合中是否已經存在該對象了?(注意:集合中不容許重複的元素存在)
也許大多數人都會想到調用equals方法來逐個進行比較,這個方法確實可行。可是若是集合中已經存在一萬條數據或者更多的數據,若是採用equals方法去逐一比較,效率必然是一個問題。此時hashCode方法的做用就體現出來了,當集合要添加新的對象時,先調用這個對象的hashCode方法,獲得對應的hashcode值,實際上在HashMap的具體實現中會用一個table保存已經存進去的對象的hashcode值,若是table中沒有該hashcode值,它就能夠直接存進去,不用再進行任何比較了;若是存在該hashcode值, 就調用它的equals方法與新元素進行比較,相同的話就不存了,不相同就散列其它的地址,因此這裏存在一個衝突解決的問題,這樣一來實際調用equals方法的次數就大大下降了,說通俗一點:Java中的hashCode方法就是根據必定的規則將與對象相關的信息(好比對象的存儲地址,對象的字段等)映射成一個數值,這個數值稱做爲散列值。下面這段代碼是java.util.HashMap的中put方法的具體實現:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
public
V put(K key, V value) {
if
(key ==
null
)
return
putForNullKey(value);
int
hash = hash(key.hashCode());
int
i = indexFor(hash, table.length);
for
(Entry<K,V> e = table[i]; e !=
null
; e = e.next) {
Object k;
if
(e.hash == hash && ((k = e.key) == key || key.equals(k))) {
V oldValue = e.value;
e.value = value;
e.recordAccess(
this
);
return
oldValue;
}
}
modCount++;
addEntry(hash, key, value, i);
return
null
;
}
|
put方法是用來向HashMap中添加新的元素,從put方法的具體實現可知,會先調用hashCode方法獲得該元素的hashCode值,而後查看table中是否存在該hashCode值,若是存在則調用equals方法從新肯定是否存在該元素,若是存在,則更新value值,不然將新的元素添加到HashMap中。從這裏能夠看出,hashCode方法的存在是爲了減小equals方法的調用次數,從而提升程序效率。
1. cookie 和 session 的區別
cookie機制採用的是在客戶端保持狀態的方案,
而session機制採用的是在服務器端保持狀態的方案。
一、cookie數據存放在客戶的瀏覽器上,session數據放在服務器上。
二、cookie不是很安全,別人能夠分析存放在本地的COOKIE並進行COOKIE欺騙
考慮到安全應當使用session。
三、session會在必定時間內保存在服務器上。當訪問增多,會比較佔用你服務器的性能
考慮到減輕服務器性能方面,應當使用COOKIE。
四、單個cookie保存的數據不能超過4K,不少瀏覽器都限制一個站點最多保存20個cookie。
五、
將登錄信息等重要信息存放爲SESSION
其餘信息若是須要保留,能夠放在COOKIE中
2. JVM 內存模型
3. SQL注入的原理
4. 悲觀鎖 和 樂觀鎖
5. 讀程序,輸出結果. 關於treemap的
6. Linux 基礎命令,統計日誌中的信息
7. java 分佈式集羣
8. 一道設計題,具體到數據庫的表.大概是淘寶的搜索中,輸入手機,會出來不少類型,按品牌按價格區間按手機種類.
還有2道題我記不住了.
面試:
1.介紹你作過的項目,用到的技術,涉及到的模塊,而後從項目中問各類技術實現的細節(爲了確保你是真的懂了).
2.看你的試卷,喊你講解作題的思路,以及這樣結果的緣由.(考的是各位的java基礎知識了,這點是繞不過去的,懂了就懂了啊,只有平時多看書)
3.團購6位驗證碼以及團購成功後,發送到你手機上的條碼的實現方式.(第一個問題我說用隨機數+時間來驗證.第二個問題老實說,我也沒答上來,我說用序列,面試官說序列到後期20位以上的時候,用戶體驗不好的)
4.淘寶上是如何保證庫存和訂單之間的數據準確性的.(考點是分佈式事務,這個問題我也沒答上來,最後他問我有什麼問題問他的時候,我就反問的這個問題,面試官人挺好的,給我耐心的講解了一遍淘寶的實現方式以及
epay的實現方式. 淘寶是經過分佈式事物,中間用了一個叫協調者角色的程序,當那邊點擊購買時,會庫存減一,保存一條預扣的狀態,可是是個預準備狀態,而後作成功後,協調者會在另外一個數據庫生成訂單,而後這個訂單也是預狀態,等兩邊都準備好之後,通知協調者,又協調者統一完成這2個數據庫的事物,從而達到完成一筆交易的目的,若其中一方失敗,則將預扣的數字返回到庫存從而實現相似回滾的操做.)
5.索引的原理.可否構建時間索引.時間索引構建後會存在什麼問題.(索引原理我是回答的堆表索引的構建原理以及查詢原理,可是關於時間索引的問題,我也沒回答出個因此然來,看面試官的反饋,好像回答得不夠好吧)
6.大家數據庫的數據量有多大,(回答:咱們是電信方面的系統,表上億的數據很正常).問:若是保證效率?
(我是如此回答的,各位自行結合自身的狀況參考.答:後臺J OB程序會按期備份,把生產表數據移走,而後備份表也會再備份一次,如此剃度的備份,保證生產庫的數據是最小的.而後備份表採用分區和子分區,加上構建戰略索引(分析系統的sql,經常使用
查詢字段構建複合索引,以減小每次查詢時對錶的訪問次數)).
7.SQL注入的原理以及如何預防,並舉例.(這個相對簡單,網上一搜一大片)
8.使用過Memcache麼? 用在項目中哪些地方? (答,在門戶主機上使用,緩存session,分佈式的時候,統一訪問這臺主機驗證用戶session是否存在,來維持回話的狀態和實現回話同步.又追問:java代碼中如何實現訪問門戶服務器的這個session池子的? 幾年前的代碼,確實忘記了..因而坦白的說,記不清楚了 )
這些是主要的問題,當你回答一個大問題時中間還有不少比較碎的追問性質的小問題,整體給個人感受是,氛圍很輕鬆+愉快的,技術層面上仍是須要你真正的理解透徹一些關鍵技術點,才能作到應付各類追問和給出滿意的答案吧.若是隻是隻知其一;不知其二想去矇混過關確定是不行的,畢竟在支付寶的技術大牛面前,多追問幾句,也就把你逼到死角了.
還有一點比較重要的感受就是,他們比較在乎你是否瞭解當下的一些比較熱的技術點,好比淘寶的秒殺,是如何保證高併發下的安全性和性能,新浪微博那種大數據量的發送,怎麼就保證正確性和時效性的.