1. cookie 和 session 的區別

cookie機制採用的是在客戶端保持狀態的方案，
  而session機制採用的是在伺服器端保持狀態的方案。
1、cookie資料存放在客戶的瀏覽器上，session資料放在伺服器上。
2、cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙
      考慮到安全應當使用session。
3、session會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能
   考慮到減輕伺服器效能方面，應當使用COOKIE。
4、單個cookie儲存的資料不能超過4K，很多瀏覽器都限制一個站點最多儲存20個cookie。
5、
   將登陸資訊等重要資訊存放為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池子的? 幾年前的程式碼,確實忘記了..於是坦白的說,記不清楚了 )

這些是主要的問題,當你回答一個大問題時中間還有很多比較碎的追問性質的小問題,總體給我的感覺是,氛圍很輕鬆+愉快的,技術層面上還是需要你真正的理解透徹一些關鍵技術點,才能做到應付各種追問和給出滿意的答案吧.如果只是一知半解想去矇混過關肯定是不行的,畢竟在支付寶的技術大牛面前,多追問幾句,也就把你逼到死角了.

還有一點比較重要的感覺就是,他們比較在意你是否瞭解當下的一些比較熱的技術點,比如淘寶的秒殺,是如何保證高併發下的安全性和效能,新浪微博那種大資料量的傳送,怎麼就保證正確性和時效性的.