hashMap、hashtable、ConcurrentHashMap、hashset的區(qū)別 hashMap
1）允許空值和空健
2）線程不安全，效率高于hashtable
3）HashMap把Hashtable的contains方法去掉了，改成containsvalue和containsKey
3）HashMap中hash數(shù)組的默認大小是16，而且一定是2的指數(shù)。
4）JDK1.2出現(xiàn)的
hashtable
1）不允許空健和空值
2）線程安全，效率低于hashMap
3）HashTable中hash數(shù)組默認大小是11，增加的方式是 old*2+1
3）JDK1.0出現(xiàn)的
ConcurrentHashMap
1）一個ConcurrentHashMap由多個segment組成，每一個segment都包含了一個HashEntry數(shù)組的hashtable
2）每一個segment包含了對自己的hashtable的操作，比如get，put，replace等操作，這些操作發(fā)生的時候，對自己的hashtable進行鎖定。由于每一個segment寫操作只鎖定自己的hashtable，所以可能存在多個線程同時寫的情況，性能無疑好于只有一個hashtable鎖定的情況， 高并發(fā)
hashset
1）只能放入單獨的對象
2）放入的元素無序
3）放入的元素不能夠重復
4）HashSet 底層采用 HashMap來保存所有元素 所有放入 HashSet 中的集合元素實際上由HashMap 的 key 來保存，而 HashMap 的 value 則存儲了一個 PRESENT，它是一個靜態(tài)的 Object對象。
將一個字符串反轉：
System.out.println(newStringBuilder("i love you ").reverse().toString());
String str="i Loveyou";
List list = newArrayList();
String splitStr []=str.split("");
list=Arrays.asList(splitStr);
Collections.reverse(list);
for(Stringword:list){
System.out.print(word+" ");
volatile、synchronized、final、wait、notify的含義 Volatile:
Volatile修飾的成員變量在每次被線程訪問時，都強迫從共享內存中重讀該成員變量的值。而且，當成員變量發(fā)生變化時，強迫線程將變化值回寫到共享內存。這樣在任何時刻，兩個不同的線程總是看到某個成員變量的同一個值。 volatile是變量修飾符，用在多線程，同步變量。線程為了提高效率，將某成員變量(如A)拷貝了一份（如B），線程中對A的訪問其實訪問的是B。只在某些動作時才進行A和B的同步。因此存在A和B不一致的情況。volatile就是用來避免這種情況的。volatile告訴jvm，它所修飾的變量不保留拷貝，直接訪問主內存中的（也就是上面說的A)
在Java內存模型中，有mainmemory，每個線程也有自己的memory(例如寄存器)。為了性能，一個線程會在自己的memory中保持要訪問的變量的副本。這樣就會出現(xiàn)同一個變量在某個瞬間，在一個線程的memory中的值可能與另外一個線程memory中的值，或者mainmemory中的值不一致的情況。
一個變量聲明為volatile，就意味著這個變量是隨時會被其他線程修改的，因此不能將它cache在線程memory中。
public class StoppableTask extends Thread {
private volatile boolean pleaseStop;
public void tellMeToStop() {
假如pleaseStop沒有被聲明為volatile，線程執(zhí)行run的時候檢查的是自己的副本，就不能及時得知其他線程已經(jīng)調用tellMeToStop()修改了pleaseStop的值。
Synchronized:
synchronized獲得并釋放監(jiān)視器，如果兩個線程使用了同一個對象鎖，監(jiān)視器能強制保證代碼塊同時只被一個線程所執(zhí)行
因此volatile只是在線程內存和“主”內存間同步某個變量的值，而synchronized通過鎖定和解鎖某個監(jiān)視器同步所有變量的值。
顯然synchronized要比volatile消耗更多資源。
Final:
用于修飾變量屬性、方法和類
修飾變量屬性:如果變量為基本數(shù)據(jù)類型表示為常量不能修改其值；如果為引用類型表示變量的引用不能指向新的對象
修飾方法表示改方法不可重寫
修飾類表示改類不可繼承
Wait：
wait是Object類中的方法且不能夠被重寫
wait方法只能放在同步的方法貨同步塊中，表示資源同步時線程需要等待
wait會自動釋放對象鎖
wait方法需要等待線程喚醒后，線程才會繼續(xù)執(zhí)行，靠別人來喚醒
Notify：
線程的通信，用于喚醒線程；這里wait和notify方法必須要與sysnchronized一起使用，也就是wait與notify只針對已經(jīng)獲得對象鎖進行操作，從語法角度wait與notify必須在sysnchronized(Obj){}語句塊中，從功能上講wait就是說線程在獲取對象后，主動釋放對象鎖，同時本地線程休眠。直到有其他線程調用對象的notify方法對對象鎖進行喚醒操作，notify調用后并不是馬上釋放對象鎖，而是在相應的sysnchronized語句塊執(zhí)行結束，自動釋放后，jvm會在wait對象鎖的線程中隨機選取一段線程賦予對象鎖，喚醒線程繼續(xù)執(zhí)行，這樣提供了在線程間同步、喚醒的操作.
java內存模型并做簡要說明。
JVM具有一個堆，堆是運行時數(shù)據(jù)區(qū)域，所有的實例和數(shù)組的內存均從這里進行分配，內存中又分為棧、堆、數(shù)據(jù)段等的概念.
內存模型中有主內存和工作內存，類似于電腦中的閃存和高速緩存樣，線程使用的數(shù)據(jù)庫在主內存中，然后對數(shù)據(jù)庫的操作，為了獲得更快的速度，會放到寄存器和高速緩存中，java類型模型規(guī)定所有的變量都存儲在主內存中，而工作閃存會放到變量的副本拷貝，線程對所有變量的操作都在工作內存中進行，而且不同的線程不能訪問對方工作內存中的變量 ，只能夠通過主內存進行訪問.
Java線程之間的通信由Java內存模型控制.JMM決定一個線程對共享變量的寫入何時對另一個線程可見,Java的并發(fā)采用的是共享內存模型.
主內存和工作內存之間的具體交互協(xié)議，即變量如何從主內存到工作內存，然后又從工作內存回到主內存的實現(xiàn)細節(jié)，JAVA內存模型定義了以下8中操作完成，虛擬機實現(xiàn)時，必須保證下面的每一種操作都是原子的、不可分割的
1.lock(鎖定) 作用于主內存的變量，它把變量表示成為一條線程獨占的狀態(tài)。
2.unlock(解鎖)作用于主內存的變量，它把一個處于鎖定狀態(tài)的變量釋放出來，解鎖后才能被其他線程鎖定
3.read(讀取)：作用于主內存的變量，它把主內存的變量值傳輸?shù)骄€程對應的工作內存中，等待load
4.load(載入) 作用于工作內存的變量，它把從read操作從主內存中得到的變量值，放入到工作內存的變量副本中。
5.use(使用) 作用于工作內存的變量，它把工作內存的變量的值傳遞給執(zhí)行引擎，每當虛擬機遇到一個需要使用的變量的值的字
節(jié)碼指令時，將會執(zhí)行這個操作。
6.assigin(賦值) 作用于工作內存的變量，它把一個從執(zhí)行引擎接收到的值給工作內存的變量，每當虛擬機遇到一個給變量賦值的
字節(jié)碼指令時執(zhí)行這個操作。
7.store(存儲) 作用于工作內存的變量，它把工作內存中的一個變量的值傳送到主內存中，以便write操作
8.write(寫入) 作用于主內存的變量，它把store操作從工作內存中得到的變量值放到主內存變量中。
什么是“異步模型”，與同步模型比有什么優(yōu)點。
1、 如果做一件事情是有順序的，先做完Task1，再做Task2，最后做Task3，這類事情也是我們日常見的最多的一種情況
2、如果做一件事情并沒有順序之分，可以同時進行，每一件事情也是相對獨立的，其實這就是一種同步模型。當然，其實這也是一種理想
情況，在大多數(shù)情況下，進程之間或線程之間往往要進行通信，一個任務會等待另外一個任務的返回結果，這就有些較為復雜了
3、在異步模型中，任務是交替運行的，但仍然在一個進程中，其中每個任務的運行狀態(tài)都是可以被我們控制的
異步模型與同步模型有什么區(qū)別嗎？
a) 同步模型中的任務交替運行，是需要多個線程協(xié)同完成的，受到程序的控制，而在異步模型中則不需要。
b)多線程本身就受到操作系統(tǒng)的調度與管理，所以同步模型本身就受到操作系統(tǒng)控制的，而在異步模型中一個任務會一直運行下去，直到任務被運行完或者程序暫停這個任務而去執(zhí)行令一個任務
c) 異步模型比同步模型簡單，因為異步模型只有一個進程而且任務的停止和運行狀態(tài)是可控的。而在同步模型中，我們需要把每一個任務分成很多步驟，然后再有序的把他們組合起來
d） 如果程序中會有阻塞、被強迫等待等情況，異步模型會比同步模型運行速度快, 異步程序設計的原理就是當其中一個任務被阻塞的時候，可以先去執(zhí)行一些其他可以執(zhí)行的任務所以一個異步程序也會被叫做“無阻塞程序”。
那什么時候，我們需要考慮使用異步模型呢？
a) 有很多任務，經(jīng)常總有一個任務可以繼續(xù)執(zhí)行
b) 這些任務中要執(zhí)行很多I/O操作
c) 這些任務大多都是獨立的
列舉你常用的模式，重點說明觀察者模式。
單例模式、工廠模式、觀察者模式
又稱作”發(fā)布—訂閱”模式。定義了一種一對多的依賴關系. 讓多個觀察者對象同時監(jiān)聽某一個主題對象, 這個主題對象
在狀態(tài)發(fā)生變化的時候,會通知所有的觀察者對象,使他們能夠自動更新自己。
什么時候使用:
當一個對象的改變需要同時通知其他對象的時候, 而且它不知道具體有多少對象需要通知的時候,需要通知的對象能夠動態(tài)地增加
為什么要使用觀察者模式？
交互對象之間的松耦合設計使得觀察者和主題之間達到一個松耦合。
觀察者模式的組成：
觀察者模式的靜態(tài)結構中包含這樣一些角色：
1）抽象主題角色subject:
2）抽象觀察者角色Observer
3）具體主題角色（concreteSubject）
4）具體觀察者(ConcreteObserver)角色
什么時候會產(chǎn)生outofmeoryErrorException，并說明產(chǎn)生原因。
原因：常見的有以下幾種：
1.內存中加載的數(shù)據(jù)量過于龐大，如一次從數(shù)據(jù)庫取出過多數(shù)據(jù)；
2.集合類中有對對象的引用，使用完后未清空，使得JVM不能回收；
3.代碼中存在死循環(huán)或循環(huán)產(chǎn)生過多重復的對象實體；
4.使用的第三方軟件中的BUG；
5.啟動參數(shù)內存值設定的過?。?/p>
把啟動參數(shù)內存值設置足夠大。
2.Java代碼導致錯誤的解決：
重點排查以下幾點：
1)檢查代碼中是否有死循環(huán)或遞歸調用。
2)檢查是否有大循環(huán)重復產(chǎn)生新對象實體。
3)檢查對數(shù)據(jù)庫查詢中，是否有一次獲得全部數(shù)據(jù)的查詢。一般來說，如果一次取十萬條記錄到內存，就可能引起內存溢出。這個問題比較隱蔽，在上線前，數(shù)據(jù)庫中數(shù)據(jù)較少，不容易出問題，上線后，數(shù)據(jù)庫中數(shù)據(jù)多了，一次查詢就有可能引起內存溢出。因此對于數(shù)據(jù)庫查詢盡量采用分頁的方式查詢。
4 )檢查List、MAP等集合對象是否有使用完后，未清除的問題。List、MAP等集合對象會始終存有對對象的引用，使得這些對象不能被GC回收。
案例：
1.hibernate查詢數(shù)據(jù)時，一次查詢過多的數(shù)據(jù)，后來調整了該部分的代碼，每次只取出指定量的數(shù)據(jù)，成功的解決該問題。
2.在做壓力測試時，出現(xiàn)OutOfMemoryError，發(fā)現(xiàn)session的資源一直沒有被釋放產(chǎn)生的，最好通過session的invalidate()方法將session的資源釋放。
3.程序中出現(xiàn)死循環(huán)。
4.tomcat部署、運行出現(xiàn)OutOfMemoryError，加大內存參數(shù)值，解決此問題。
如果讓你設計一個高并發(fā)、高可用、實時性很高的網(wǎng)站，談談你對架構的設計。
軟件負載均衡系統(tǒng)價格較低或者免費，效率較硬件負載均衡系統(tǒng)低，不過對于流量一般或稍大些網(wǎng)站來講也足夠使用，比如lvs。
目前普遍使用Squid或者nginx,或者Lighttpd，Varish。
Lighttpd：反向代理能力一般，處理FastCGI比較好，消耗內存很小
Varish：主要做內存的反向代理，性能最優(yōu)
由Apache負責解析PHP內容，也可以用Nginx，或者Lighttpd，相對來說Apache比較穩(wěn)定。
存儲量很大，經(jīng)常會達到單臺服務器無法提供的規(guī)模，比如相冊、視頻等應用。因此需要專業(yè)的大規(guī)模存儲系統(tǒng)。
根據(jù)各自需要由C/C++開發(fā)設計供上層CGI調用。
1)使用MySQL數(shù)據(jù)庫，考慮到Web應用的數(shù)據(jù)庫讀多寫少的特點，我們主要對讀數(shù)據(jù)庫做了優(yōu)化，提供專用的讀數(shù)據(jù)庫和寫數(shù)據(jù)庫，在應用程序中實現(xiàn)讀操作和寫操作分別訪問不同的數(shù)據(jù)庫。
2)使用同步機制實現(xiàn)快速將主庫(寫庫)的數(shù)據(jù)庫復制到從庫(讀庫)。一個主庫對應多個從庫，主庫數(shù)據(jù)實時同步到從庫。
3)寫數(shù)據(jù)庫有多臺，每臺都可以提供多個應用共同使用，這樣可以解決寫庫的性能瓶頸問題和單點故障問題。
也可以從這些方面考慮(前端優(yōu)化、運用緩存、代理層、數(shù)據(jù)庫層、負載均衡層、業(yè)務層)
前端優(yōu)化:
具體參考：yahoo前端優(yōu)化34條規(guī)則，針對12306平臺，個人建議在沒有多運營商鏈路接入(如BGP)的情況下繼續(xù)使用CDN進行加速。動、靜態(tài)應用分離，靜態(tài)業(yè)務使用非12306.cn域名可以減少無用cookie帶來的流量。任何一個小細節(jié)在高并發(fā)下都會被無限放大(截止目前發(fā)現(xiàn)平臺還是以dynamic.12306.cn域名做靜態(tài)引用)。查詢頁面的結果是通過Ajax異步返回填充iframe框架來實現(xiàn)，這對動態(tài)CDN加速是一個挑戰(zhàn)，因為CDN節(jié)點并沒有真正緩存頁面中主要加速的內容。另外提高驗證碼的復雜度及多樣性，可以緩解刷票機給平臺帶來的壓力。
運用緩存:
緩存最大的好處是減少后端數(shù)據(jù)存儲的I/O壓力，從一個普通用戶訂票軌跡來看，查詢讀往往是入庫寫的好幾倍，如何減少數(shù)據(jù)庫的讀I/O對提高平臺的整體性能至關重要，比較流行的緩存技術有針對頁面及數(shù)據(jù)級，頁面級緩存有varnish、squid等，如使用CDN，頁面級的緩存可以不用考慮，重點將精力放在數(shù)據(jù)級的緩存規(guī)劃上，技術方面可以用Nosql來實現(xiàn)，比較成熟的Nosql有memcached、redis、mongodb等?？梢愿鶕?jù)班次、出發(fā)與目的地ID組合或出發(fā)日期進行hash分區(qū)，這樣可以很好地提高緩存命中率，減少后端數(shù)據(jù)庫的壓力。
代理層:
引入代理層的目的是拆分業(yè)務，目前平臺絕大部分功能都共用一組WEB服務器(從域名及URI結構猜測，不一定準確)來對外提供服務，比如登錄、注冊、車票查詢、余票查詢、列車時刻表查詢、正晚點查詢、訂單管理等等，只要其中一個功能模塊出現(xiàn)堵塞，影響必定是全局性的。一個好的方法是優(yōu)化、規(guī)范各業(yè)務URI，在代理層實現(xiàn)業(yè)務的劃分，可用的技術有Haproxy、Nginx等，如將/otsweb/regitNote/映射到注冊組WEB服務器，/otsweb/AppQuery/映射到查詢組WEB服務器，/otsweb/Pay/映射到支付組WEB服務器等等，如此一來，當查詢業(yè)務出現(xiàn)延時堵塞時不會影響到用戶支付。
數(shù)據(jù)庫層:
之前接觸過一些政府行業(yè)的業(yè)務，數(shù)據(jù)庫服務器往往都使用一臺高端的硬件，比如小型機，在互聯(lián)網(wǎng)行業(yè)，尤其是類似于12306訂票系統(tǒng)，這往往是最致命的，理由很簡單，在大流量并發(fā)下處理能力再強的服務器也吐不出數(shù)據(jù)，因為受網(wǎng)絡I/O、磁盤I/O、業(yè)務邏輯等方面的限制，所以必須將數(shù)據(jù)打散，方案有進行讀寫分離、分區(qū)、分片。主從模式可以很好實現(xiàn)讀寫分離，大部分數(shù)據(jù)庫都支持這點，除此之外還建議使用分區(qū)模式，分區(qū)策略可以根據(jù)業(yè)務特點進行，按地域進行分區(qū)是一個好主意，因為每個區(qū)域都是一個大分區(qū)，還可以從業(yè)務層面對它做二級甚至三級的"擴展分區(qū)"。需要在細化拆分與運營成本上做好平衡。另外I/O密集的點盡量使用SSD代替。
負載均衡層: 保障一個業(yè)務平臺的高可用性，采用負載均衡策略必不可少，即使是提供給CDN的源服務器。目前有商用的F5、NetScaler、Radware等，也有開源的LVS，看成本的投入來選擇，此處不詳細展開討論。
業(yè)務層:
此次12306網(wǎng)站癱瘓事件，業(yè)務層面有無優(yōu)化的空間?12306網(wǎng)站平臺是鐵道集團在互聯(lián)網(wǎng)上對外服務的窗口，與電話訂票、代售點都是平級的，后端肯定還關聯(lián)著很多復雜的業(yè)務系統(tǒng)，在沒有對整個集團業(yè)務系統(tǒng)做擴容的前提下(短期內估計不能實現(xiàn))，可以將網(wǎng)站業(yè)務平臺剝離出來，當然，完全剝離也不太實際，至少可以延長同步、一致性校驗的時間。時間的長短隨班次的發(fā)車時間成正比，因為大部分的用戶都是提前一周以上就著手預定車票。
列舉常用的開源框架和開源類庫，越多越好 spingmvc struts2 spring mybaits hibernate axis2 minapoi opencsv webworkjquery itextjunit Commons-IO
Commons-Email log4j dom4j ant mail
說明內連接、左連接、右連接、全連接的含義和區(qū)別 內連接：把兩個表中數(shù)據(jù)對應的數(shù)據(jù)查詢出來。
外連接：以某個表為基礎把對應數(shù)據(jù)查詢出來（全連接是以多個表為基礎），其中又包括左連接和右連接兩種
內連接：
把兩個表中數(shù)據(jù)對應的數(shù)據(jù)查詢出來。在兩個表中查詢滿足條件的對應數(shù)據(jù) SELECT * FROM student INNERJOIN grade ON student.no=grade.no
左連接：
包含左表中所有數(shù)據(jù)，右表中滿足條件的對應數(shù)據(jù)
SELECT * FROM student LEFT JOIN grade ONstudent.no=grade.no
右連接：包含右表中所有數(shù)據(jù)，左表中滿足條件的對應數(shù)據(jù)。
SELECT *FROM student RIGHT JOIN grade ON student.no=grade.no
全連接：
左右表中所有數(shù)據(jù)全部查詢出來。
SELECT * FROM student FULL JOIN grade ONstudent.no=grade.no
列舉你用過的MQ；
LinkedList LinkedBlockingQueue SynchronizedQuery 框架(active MQ)
系統(tǒng)之間有哪些數(shù)據(jù)交互方式； socket方式( Socket方式是最簡單的交互方式。是典型才c/s交互模式。一臺客戶機，一臺服務器。服務器提供服務，通過ip地址和端口進行服務訪問。而客戶機通過連接服務器指定的端口進行消息交互。其中傳輸協(xié)議可以是tcp/UDP協(xié)議。而服務器和約定了請求報文格式和響應報文格式 ,傳輸協(xié)議可以是tcp/UDP)
ftp/文件共享服務器方式(系統(tǒng)A和系統(tǒng)B通過連接同一個數(shù)據(jù)庫服務器的同一張表進行數(shù)據(jù)交換。當系統(tǒng)A請求系統(tǒng)B處理數(shù)據(jù)的時候，系統(tǒng)AInsert一條數(shù)據(jù)，系統(tǒng)B select 系統(tǒng)A插入的數(shù)據(jù)進行處理。
)
webService方式(soap協(xié)議)
數(shù)據(jù)庫共享數(shù)據(jù)方式(系統(tǒng)A和系統(tǒng)B通過連接同一個數(shù)據(jù)庫服務器的同一張表進行數(shù)據(jù)交換。當系統(tǒng)A請求系統(tǒng)B處理數(shù)據(jù)的時候，系統(tǒng)AInsert一條數(shù)據(jù)，系統(tǒng)B select 系統(tǒng)A插入的數(shù)據(jù)進行處理。
)
message方式(Java消息服務（JavaMessageService）是message數(shù)據(jù)傳輸?shù)牡湫偷膶崿F(xiàn)方式。系統(tǒng)A和系統(tǒng)B通過一個消息服務器進行數(shù)據(jù)交換。系統(tǒng)A發(fā)送消息到消息服務器，如果系統(tǒng)B訂閱系統(tǒng)A發(fā)送過來的消息，消息服務器會消息推送給B。雙方約定消息格式即可。目前市場上有很多開源的jms消息中間件，比如 ActiveMQ,OpenJMS 。)
springMVC方面：
Struts2也是非常優(yōu)秀的MVC構架，優(yōu)點非常多比如良好的結構，攔截器的思想，豐富的功能。但這里想說的是缺點，Struts2由于采用了值棧、OGNL表達式、struts2標簽庫等，會導致應用的性能下降，應避免使用這些功能。
1. 機制：springmvc的入口是servlet，而struts2是filter（這里要指出，filter和servlet是不同的。以前認為filter是servlet的一種特殊），這樣就導致了二者的機制不同，這里就牽涉到servlet和filter的區(qū)別了。
2.性能：spring會稍微比struts快。springmvc是基于方法的設計，而sturts是基于類，每次發(fā)一次請求都會實例一個action，每個action都會被注入屬性，而spring基于方法，粒度更細，但要小心把握像在servlet控制數(shù)據(jù)一樣。spring3mvc是方法級別的攔截，攔截到方法后根據(jù)參數(shù)上的注解，把request數(shù)據(jù)注入進去，在spring3mvc中，一個方法對應一個request上下文。而struts2框架是類級別的攔截，每次來了請求就創(chuàng)建一個Action，然后調用settergetter方法把request中的數(shù)據(jù)注入；struts2實際上是通過settergetter方法與request打交道的；struts2中，一個Action對象對應一個request上下文。
3.參數(shù)傳遞：struts是在接受參數(shù)的時候，可以用屬性來接受參數(shù)，這就說明參數(shù)是讓多個方法共享的。
4. 設計思想上：struts更加符合oop的編程思想，spring就比較謹慎，在servlet上擴展。
5.intercepter的實現(xiàn)機制：struts有以自己的interceptor機制，springmvc用的是獨立的AOP方式。這樣導致struts的配置文件量還是比springmvc大，雖然struts的配置能繼承，所以我覺得論使用上來講，springmvc使用更加簡潔，開發(fā)效率SpringMVC確實比struts2高。springmvc是方法級別的攔截，一個方法對應一個request上下文，而方法同時又跟一個url對應，所以說從架構本身上spring3 mvc就容易實現(xiàn)restfulurl。struts2是類級別的攔截，一個類對應一個request上下文；實現(xiàn)restfulurl要費勁，因為struts2action的一個方法可以對應一個url；而其類屬性卻被所有方法共享，這也就無法用注解或其他方式標識其所屬方法了。spring3mvc的方法之間基本上獨立的，獨享requestresponse數(shù)據(jù)，請求數(shù)據(jù)通過參數(shù)獲取，處理結果通過ModelMap交回給框架方法之間不共享變量，而struts2搞的就比較亂，雖然方法之間也是獨立的，但其所有Action變量是共享的，這不會影響程序運行，卻給我們編碼，讀程序時帶來麻煩。
6. 另外，spring3mvc的驗證也是一個亮點，支持JSR303，處理ajax的請求更是方便，只需一個注解@ResponseBody ，然后直接返回響應文本即可。送上一段代碼：
@RequestMapping(value="/whitelists")
public String index(ModelMap map) {
Account account =accountManager.getByDigitId(SecurityContextHolder.get().getDigitId());
List groupList = groupManager.findAllGroup(account.getId());
map.put("account", account);
map.put("groupList", groupList);
return "/group/group-index";
}
// @ResponseBody ajax響應，處理Ajax請求也很方便
@RequestMapping(value="/whitelist/{whiteListId}/del")
@ResponseBody
public String delete(@PathVariable Integer whiteListId) {
whiteListManager.deleteWhiteList(whiteListId);
return "success";
}
servlet和filter的區(qū)別 ：
Filter可認為是Servlet的一種“變種”，它主要用于對用戶請求進行預處理，也可以對HttpServletResponse進行后處理，是個典型的處理鏈。它與Servlet的區(qū)別在于：它不能直接向用戶生成響應。完整的流程是：Filter對用戶請求進行預處理，接著將請求交給 Servlet進行處理并生成響應，最后Filter再對服務器響應進行后處理。
servlet 生命周期：
(1)容器加載servlet文件(2)創(chuàng)建servlet實例 (3)調用servlet中的init()方法進行初始化資源(4)調用servlet中的service()方法進行線程并發(fā)處理 (5)調用servlet的destroy方法進行銷毀操作
get與post：
1.get從服務器上獲取數(shù)據(jù)post向服務器傳送數(shù)據(jù)
2.get把參數(shù)數(shù)據(jù)隊列加提交表單ACTION屬性所指URL值和表單內各字段對應URL看post通過HTTPpost機制表單內各字段與其內容放置HTML HEADER內起傳送ACTION屬性所指URL地址用戶看過程
3.對于get方式服務器端用Request.QueryString獲取變量值對于post方式服務器端用Request.Form獲取提交數(shù)據(jù)
4.get傳送數(shù)據(jù)量較小能大于2KBpost傳送數(shù)據(jù)量較大般被默認受限制理論上IIS4大量80KBIIS5100KB
5.get安全性非常低post安全性較高執(zhí)行效率卻比Post方法好
建議：
1、get方式安全性較Post方式要差些包含機密信息建議用Post數(shù)據(jù)提交方式；
2、做數(shù)據(jù)查詢時建議用Get方式；而做數(shù)據(jù)添加、修改或刪除時建議用Post方式；
悲觀鎖與樂觀鎖的引入：
在多用戶環(huán)境中，在同一時間可能會有多個用戶更新相同的記錄，這會產(chǎn)生沖突。這就是著名的并發(fā)性問題。
典型的沖突有：
l 丟失更新：一個事務的更新覆蓋了其它事務的更新結果，就是所謂的更新丟失。例如：用戶A把值從6改為2，用戶B把值從2改為6，則用戶A丟失了他的更新。
l 臟讀：當一個事務讀取其它完成一半事務的記錄時，就會發(fā)生臟讀取。例如：用戶A,B看到的值都是6，用戶B把值改為2，用戶A讀到的值仍為6。
為了解決這些并發(fā)帶來的問題。我們需要引入并發(fā)控制機制。
并發(fā)控制機制
最常用的處理多用戶并發(fā)訪問的方法是加鎖。當一個用戶鎖住數(shù)據(jù)庫中的某個對象時，其他用戶就不能再訪問該對象。加鎖對并發(fā)訪問的影響體現(xiàn)在鎖的粒度上。比如，放在一個表上的鎖限制對整個表的并發(fā)訪問；放在數(shù)據(jù)頁上的鎖限制了對整個數(shù)據(jù)頁的訪問；放在行上的鎖只限制對該行的并發(fā)訪問?？梢娦墟i粒度最小，并發(fā)訪問最好，頁鎖粒度最大，表鎖介于2者之間。
悲觀鎖：假定會發(fā)生并發(fā)沖突，屏蔽一切可能違反數(shù)據(jù)完整性的操作。[1] 悲觀鎖假定其他用戶企圖訪問或者改變你正在訪問、更改的對象的概率是很高的，因此在悲觀鎖的環(huán)境中，在你開始改變此對象之前就將該對象鎖住，并且直到你提交了所作的更改之后才釋放鎖。悲觀的缺陷是不論是頁鎖還是行鎖，加鎖的時間可能會很長，這樣可能會長時間的限制其他用戶的訪問，也就是說悲觀鎖的并發(fā)訪問性不好。
樂觀鎖：假設不會發(fā)生并發(fā)沖突，只在提交操作時檢查是否違反數(shù)據(jù)完整性。[1] 樂觀鎖不能解決臟讀的問題。 樂觀鎖則認為其他用戶企圖改變你正在更改的對象的概率是很小的，因此樂觀鎖直到你準備提交所作的更改時才將對象鎖住，當你讀取以及改變該對象時并不加鎖?？梢姌酚^鎖加鎖的時間要比悲觀鎖短，樂觀鎖可以用較大的鎖粒度獲得較好的并發(fā)訪問性能。但是如果第二個用戶恰好在第一個用戶提交更改之前讀取了該對象，那么當他完成了自己的更改進行提交時，數(shù)據(jù)庫就會發(fā)現(xiàn)該對象已經(jīng)變化了，這樣，第二個用戶不得不重新讀取該對象并作出更改。這說明在樂觀鎖環(huán)境中，會增加并發(fā)用戶讀取對象的次數(shù)。
從數(shù)據(jù)庫廠商的角度看，使用樂觀的頁鎖是比較好的，尤其在影響很多行的批量操作中可以放比較少的鎖，從而降低對資源的需求提高數(shù)據(jù)庫的性能。再考慮聚集索引。在數(shù)據(jù)庫中記錄是按照聚集索引的物理順序存放的。如果使用頁鎖，當兩個用戶同時訪問更改位于同一數(shù)據(jù)頁上的相鄰兩行時，其中一個用戶必須等待另一個用戶釋放鎖，這會明顯地降低系統(tǒng)的性能。interbase和大多數(shù)關系數(shù)據(jù)庫一樣，采用的是樂觀鎖，而且讀鎖是共享的，寫鎖是排他的。可以在一個讀鎖上再放置讀鎖，但不能再放置寫鎖；你不能在寫鎖上再放置任何鎖。鎖是目前解決多用戶并發(fā)訪問的有效手段。
樂觀鎖應用
1. 使用自增長的整數(shù)表示數(shù)據(jù)版本號。更新時檢查版本號是否一致，比如數(shù)據(jù)庫中數(shù)據(jù)版本為6，更新提交時version=6+1,使用該version值(=7)與數(shù)據(jù)庫version+1(=7)作比較，如果相等，則可以更新，如果不等則有可能其他程序已更新該記錄，所以返回錯誤。
2. 使用時間戳來實現(xiàn).
注：對于以上兩種方式,Hibernate自帶實現(xiàn)方式：在使用樂觀鎖的字段前加annotation:@Version, Hibernate在更新時自動校驗該字段。
悲觀鎖應用
需要使用數(shù)據(jù)庫的鎖機制，比如SQL SERVER的TABLOCKX（排它表鎖） 此選項被選中時，SQL Server 將在整個表上置排它鎖直至該命令或事務結束。這將防止其他進程讀取或修改表中的數(shù)據(jù)。
SqlServer中使用
Begin Tran
select top 1 @TrainNo=T_NO
from Train_ticket with(UPDLOCK) whereS_Flag=0
update Train_ticket
set T_Name=user,
T_Time=getdate(),
S_Flag=1
where T_NO=@TrainNo
commit
我們在查詢的時候使用了with(UPDLOCK)選項,在查詢記錄的時候我們就對記錄加上了更新鎖,表示我們即將對此記錄進行更新.注意更新鎖和共享鎖是不沖突的,也就是其他用戶還可以查詢此表的內容,但是和更新鎖和排它鎖是沖突的.所以其他的更新用戶就會阻塞.
結論
在實際生產(chǎn)環(huán)境里邊,如果并發(fā)量不大且不允許臟讀，可以使用悲觀鎖解決并發(fā)問題；但如果系統(tǒng)的并發(fā)非常大的話,悲觀鎖定會帶來非常大的性能問題,所以我們就要選擇樂觀鎖定的方法.
數(shù)據(jù)庫的優(yōu)化方案： 數(shù)據(jù)庫性能最關鍵的因素在于IO,因為操作內存是快速的，但是讀寫磁盤的速度是很慢的，優(yōu)化數(shù)據(jù)庫最關鍵的問題在于減少磁盤的IO操作，個人理解應分為物理和邏輯的優(yōu)化，物理是指oracle產(chǎn)品本身的一些優(yōu)化，邏輯優(yōu)化是指應用程序級別的優(yōu)化
物理優(yōu)化的一些原則：
1）Oracle的運行環(huán)境（網(wǎng)絡，硬件等）
2）使用合適的優(yōu)化器
3）合理配置oracle實例參數(shù)
4）建立合適的索引（減少IO）
5）將索引數(shù)據(jù)和表數(shù)據(jù)分開在不同的表空間上（降低IO沖突）
6）建立表分區(qū)，將數(shù)據(jù)分別存儲在不同的分區(qū)上（以空間換取時間，減少IO）
邏輯上的一些優(yōu)化
1）Sql語句使用占位符語句，并且開發(fā)時候必須按照規(guī)定編寫sql語句（如全部大寫，全部小寫等）,oracle解析語句后會放置到共享池中，如：
select * from Emp wherename=？這個語句只會在共享池中有一條，而如果是字符串的話，那就根據(jù)不同名字存在不同的語句，所以占位符效率較好
2) 數(shù)據(jù)庫不僅僅是一個存儲數(shù)據(jù)的地方，同樣是一個編程的地方，一些耗時的操作，可以通過存儲過程等在用戶較少的情況下執(zhí)行，從而錯開系統(tǒng)使用的高峰時間，提高數(shù)據(jù)庫性能
3) 盡量不使用*號，如select * fromEmp，因為要轉化為具體的列名是要查數(shù)據(jù)字典， 比較耗時
4) 選擇有效的表名
對于多表連接查詢，可能oracle的優(yōu)化器并不會優(yōu)化到這個程度， oracle中多表查詢是根據(jù)FROM字句從右到左的數(shù)據(jù)進行的，那么最好右邊的表（也就是基礎表）選擇數(shù)據(jù)較少的表，這樣排序更快速，如果有l(wèi)ink表（多對多中間表），那么將link表放最右邊作為基礎表，在默認情況下oracle會自動優(yōu)化，但是如果配置了優(yōu)化器的情況下，可能不會自動優(yōu)化，所以平時最好能按照這個方式編寫sql
5 )Where字句規(guī)則：
Oracle中Where字句時從右往左處理的，表之間的連接寫在其他條件之前，能過濾掉非常多的數(shù)據(jù)的條件，放在where的末尾，另外！=符號比較的列將不使用索引，列經(jīng)過了計算（如變大寫等）不會使用索引（需要建立起函數(shù)）， is null、is notnull等優(yōu)化器不會使用索引
6)使用ExitsNot Exits 替代 In Not in
7)合理使用事務，合理設置事務隔離性，數(shù)據(jù)庫的數(shù)據(jù)操作比較消耗數(shù)據(jù)庫資源的，盡量使用批量處理，以降低事務操作次數(shù)
也可以參考我們dba給的建議：
@. SQL語句越簡單越好；
@. 要保持事務（和連接）短?。?br>@. 不使用trigger、存儲過程、自定義 函數(shù)；
@. 不使用select * ；
@. 避免使用子查詢；
@. Update的where 語句要使用索引， 且粒度要盡可能的小（估算）；
@. 改寫OR為 IN ;
@. 改寫OR為 Union;
@. 避免%前綴模糊查詢；
@. 避免count(*)操作；
@. 使用union all,避免使用union;
@. group by默認是進行排序的，如果結果無需排序，可最后加order by null;
@. 列的數(shù)據(jù)類型必須相同，再進行比較；
@. 避免大批量數(shù)據(jù)更新；
@. 分頁寫法：關于mysql的分頁優(yōu)化 寫法：（先根據(jù)過濾條件取出主鍵id進行排序，再進行join操作取出其他相關字段）
