免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

打開APP
userphoto
未登錄

開通VIP,暢享免費電子書等14項超值服

開通VIP
經(jīng)驗總結、自己出的面試題及參考
 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 run()  
  
    while (!pleaseStop)  
  
     // do some stuff...  
  
     
  
  

  public void tellMeToStop()  
  
   pleaseStop true;  
  
   
  
}
 
假如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 )檢查ListMAP等集合對象是否有使用完后,未清除的問題。List、MAP等集合對象會始終存有對對象的引用,使得這些對象不能被GC回收。


案例:
1.hibernate查詢數(shù)據(jù)時,一次查詢過多的數(shù)據(jù),后來調整了該部分的代碼,每次只取出指定量的數(shù)據(jù),成功的解決該問題。
2.在做壓力測試時,出現(xiàn)OutOfMemoryError,發(fā)現(xiàn)session的資源一直沒有被釋放產(chǎn)生的,最好通過sessioninvalidate()方法將session的資源釋放。
3.程序中出現(xiàn)死循環(huán)。
4.tomcat部署、運行出現(xiàn)OutOfMemoryError,加大內存參數(shù)值,解決此問題。



如果讓你設計一個高并發(fā)、高可用、實時性很高的網(wǎng)站,談談你對架構的設計。

負載均衡系統(tǒng)

反向代理系統(tǒng)

Web服務器系統(tǒng)

分布式存儲系統(tǒng)

底層服務系統(tǒng)

數(shù)據(jù)庫集群系統(tǒng)

第一負載均衡系統(tǒng)

負載均衡系統(tǒng)分為硬件和軟件兩種。

硬件負載均衡效率高,但是價格貴,比如F5等。

軟件負載均衡系統(tǒng)價格較低或者免費,效率較硬件負載均衡系統(tǒng)低,不過對于流量一般或稍大些網(wǎng)站來講也足夠使用,比如lvs。

第二反向代理系統(tǒng)

目前普遍使用Squid或者nginx,或者Lighttpd,Varish。

這四者又各自有很大的差異。

Squid:主要用來做反向代理,使用內存+硬盤

Nginx:可以反向代理+負載均衡+WWW解析

Lighttpd:反向代理能力一般,處理FastCGI比較好,消耗內存很小

Varish:主要做內存的反向代理,性能最優(yōu)

第三Web服務器系統(tǒng)

由Apache負責解析PHP內容,也可以用Nginx,或者Lighttpd,相對來說Apache比較穩(wěn)定。

第四分布式存儲系統(tǒng)

存儲量很大,經(jīng)常會達到單臺服務器無法提供的規(guī)模,比如相冊、視頻等應用。因此需要專業(yè)的大規(guī)模存儲系統(tǒng)。

第五底層服務系統(tǒng)

根據(jù)各自需要由C/C++開發(fā)設計供上層CGI調用。

第六數(shù)據(jù)庫系統(tǒng)

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ā)性問題。

典型的沖突有:

丟失更新:一個事務的更新覆蓋了其它事務的更新結果,就是所謂的更新丟失。例如:用戶A把值從6改為2,用戶B把值從2改為6,則用戶A丟失了他的更新。

臟讀:當一個事務讀取其它完成一半事務的記錄時,就會發(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操作取出其他相關字段)   
本站僅提供存儲服務,所有內容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權內容,請點擊舉報。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
最新JAVA面試寶典,面臨實習的我要抓緊背啦
Java中級開發(fā)工程師知識點歸納
珍藏 | Java 崗位 100道 面試題及答案詳解
Java類別問題
生活服務
分享 收藏 導長圖 關注 下載文章
綁定賬號成功
后續(xù)可登錄賬號暢享VIP特權!
如果VIP功能使用有故障,
可點擊這里聯(lián)系客服!

聯(lián)系客服