面試 java伺服器端開發

來源:互聯網
上載者:User

1.怎樣用java實現緩衝?

java有自己的緩衝輸入輸出類,比如 InputStream,FileOutputStram等 具體可以查看API,要想自己實現的話,很簡單,設定一個足夠大的位元組數組就可以了,把需要的東西放進去,就是個緩衝。

1. 緩衝為什麼要存在? 
一般情況下,一個網站,或者一個應用,它的一般形式是,瀏覽器請求應用伺服器,應用伺服器做一堆計算後再請求資料庫,
資料庫收到請求後再作一堆計算後把資料返回給應用伺服器,應用伺服器再作一堆計算後把資料返回給瀏覽器.
這個是一個標準流程.但是隨著互連網的普及,上網的人越來越多,網上的資訊量也越來越多,在這兩個越來越多的情況下
,我們的應用需要支撐的並發量就越來越多.然後我們的應用伺服器和資料庫伺服器所做的計算也越來越多,
但是往往我們的應用伺服器資源是有限的,資料庫每秒中接受請求的次數也是有限的(誰叫俺們的硬碟轉速有限呢).
如果利用有限的資源來提供儘可能大的輸送量呢,一個辦法:減少計算量,縮短請求流程(減少網路io或者硬碟io),
這時候緩衝就可以大展手腳了.緩衝的基本原理就是打破中所描繪的標準流程,在這個標準流程中,
任何一個環節都可以被切斷.請求可以從緩衝裡取到資料直接返回.這樣不但節省了時間,提高了響應速度,
而且也節省了硬體資源.可以讓我們有限的硬體資源來服務更多的使用者. 

2 緩衝可以存在於什麼地方? 
Java代碼

  1. 瀏覽器---瀏覽器和app之間---分過層的app-資料庫  

瀏覽器---瀏覽器和app之間---分過層的app-資料庫

在中,我們可以看到一次請求的一般流程,下面我們重新繪製這張圖,讓我們的結構稍微複雜一點點. 
(將app分層) 
瀏覽器---瀏覽器和app之間---分過層的app-資料庫 

理論上來將,請求的任何一個環節都是緩衝可以作用的地方.第一個環節,瀏覽器,如果資料存在瀏覽器上,

那麼對使用者來說速度是最快的,因為這個時候根本無需網路請求.第二個環節,瀏覽器和app之間,

如果緩衝加在這個地方,那麼緩衝對app來說是透明的.而且這個緩衝中存放的是完整的頁面.第三個節點,

app中本身就有幾個層次,那麼緩衝也可以放在不同的層次上,這一部分是情況或者情境比較複雜的部分

.選擇緩衝時需要謹慎.第四個環節,資料庫中也可以有緩衝,比如說mysql的querycache. 

那麼也就是說在整個請求流程的任何一點,我們都可以加緩衝.但是是所有的資料都可以放進緩衝的嗎.

當然不是,需要放進緩衝的資料總是有一些特徵的,要清楚的判斷資料是否可以被緩衝,

可以被怎樣緩衝就必須要從資料的變化特徵下手. 

資料有哪些變化特徵?最簡單的就是兩種,變和不變.我們都知道,不會變化的資料不需要每次都進行計算.

問題是難道所有的資料理論上來講都會變化,變化是世界永恒的主題.也就是說我們把資料分為變和不變兩種是不對的,

那麼就讓我們再加一個條件:時間.那麼我們就可以把資料特徵總結為一段時間內變或者不變.那麼根據這個資料特徵,

我們就可以在合適的位置和合適的緩衝類型中緩衝該資料. 

3緩衝有哪些屬性 
從物件導向的角度來看,緩衝就是一個對象,那麼是對象,必然有屬性.那麼下面我們來探討一下緩衝有哪些屬性.

以下列舉我們常用到的3個屬性. 
(1) 命中率 
命中率是指請求緩衝次數和緩衝返回正確結果次數的比例.比例越高,就證明緩衝的使用率越高. 

命中率問題是緩衝中的一個非常重要的問題,我們都希望自己緩衝的命中率能達到100%,但是往往事與願違,

而且快取命中率是衡量緩衝有效性的重要指標. 

(2) 最大元素 
緩衝中可以存放得最大元素得數量,一旦緩衝中元素數量超過這個值,那麼將會起用緩衝清空策略,

根據不同的情境合理的設定最大元素值往往可以一定程度上提高緩衝的命中率.從而更有效時候緩衝. 

(3) 清空策略 

1 FIFO ,first in first out ,最先進入緩衝得資料在緩衝空間不夠情況下(超出最大元素限制時)會被首先清理出去 
2 LFU , Less Frequently Used ,一直以來最少被使用的元素會被被清理掉。

這就要求緩衝的元素有一個hit 屬性,在緩衝空間不夠得情況下,hit 值最小的將會被清出緩衝。 
2 LRU ,Least Recently Used ,最近最少使用的,緩衝的元素有一個時間戳記,當緩衝容量滿了,

而又需要騰出地方來緩衝新的元素的時候,那麼現有緩衝元素中時間戳記離目前時間最遠的元素將被清出緩衝。 

4緩衝介質 
從硬體介質上來將無非就是兩種,記憶體和硬碟(對應應用程式層的程式來講不用考慮寄存器等問題).

但是往往我們不會從硬體上來劃分,一般的劃分方法是從技術上劃分,可以分成幾種,記憶體,硬碟檔案.資料庫. 
(1) 記憶體.將緩衝放在記憶體中是最快的選擇,任何程式直接操作記憶體都比操作硬碟要快的多,

但是如果你的資料要考慮到break down的問題,因為放在記憶體中的資料我們稱之為沒有持久話的資料

,如果硬碟上沒有備份,機器down機之後,很難或者無法恢複. 

(2) 硬碟.一般來說,很多緩衝架構會結合使用記憶體和硬碟,比如給記憶體配置的空間有滿了之後,

會讓使用者選擇把需要退出記憶體空間的資料持久化到硬碟.當然也選擇直接把資料放一份到硬碟

(記憶體中一份,硬碟中一份,down機也不怕).也有其他的緩衝是直接把資料放到硬碟上. 

(3) 資料庫.說到資料庫,可能有的人會想,之前不是講到要減少資料庫查詢的次數,

減少資料庫計算的壓力嗎,現在怎麼又用資料庫作為緩衝的介質了呢.這是因為資料庫又很多種類型,

比如berkleydb,這種db不支援sql語句,沒有sql引擎,只是key和value的儲存結構,所以速度非常的快,

在當代一般的pc上,每秒中十幾w次查詢都是沒有問題的(當然這個是根據業務特徵來決定的,

如果您訪問的資料在分布上是均勻的,那ahuaxuan可不能保證這個速度了). 

除了緩衝介質之外,ahuaxuan根據緩衝和應用的耦合程度將其劃分為local cache和remote cache. 
Local cache是指包含在應用之中的緩衝組件.而remote cache指和應用解耦在應用之外的緩衝組件.

典型的local cache有ehcache,oscache,而remote cache有大名鼎鼎的memcached. 

Localcache最大的優點是應用和cache的時候是在同一個進程內部,請求緩衝非常快速,

完全不需要網路開銷等.所以單應用,

不需要叢集或者叢集情況下cache node不需要相互連知的情況下使用local cache比較合適.

這也是java中ehcache和oscache這麼流行的原因. 
但是Local cache是有一定的缺點的,一般這種緩衝架構(比如java中的ehcache或者oscache)都是local cache.

也就是跟著應用程式走的,多個應用程式無法直接共用快取,應用叢集的情況下這個問題更加明顯,

當然也有的緩衝組件提供了叢集節點相互連知緩衝更新的功能,但是由於這個是廣播,或者是環路更新,

在緩衝更新頻繁的情況下會導致網路io開銷非常大,嚴重的時候會影響應用的正常運行.

而且如果緩衝中資料量較大得情況下使用localcache意味著每個應用都有一份這麼大得緩衝,著絕對是對記憶體的浪費. 

所以這個情況下,往往我們會選擇remote cache,比如memcached.這樣叢集或者分布式的情況下

各個應用都可以共用memcached中的資料,這些應用都通過socket和基於tcp/ip協議上層的memcached協議

直接連接到memcached,有一個app更新了memcached中的值,所有的應用都能拿到最新的值.

雖然這個時候多了很多了網路上的開銷,但是往往這種方案要比localcache廣播或環路更新cache節點要普遍的多,

而且效能也比後者高.由於資料只需要儲存一份,所以也提高了記憶體的使用率. 

通過以上分析可以看出,不管是local cache,還是remote cache在緩衝領域都有自己的一席之地,

所以ahuaxuan建議在選擇或者使用緩衝時一定要根據緩衝的特徵和我們的業務情境準確判斷使用何種緩衝.這樣才能充分發揮緩衝的功能. 

Ahuaxuan認為,緩衝的使用是架構師的必備技能,好的架構師能夠根據資料的類型,

業務的情境來準確的判斷出使用何種類型的緩衝,並且如何使用這種類型的緩衝.

在緩衝的世界裡也沒有銀彈,目前還沒有一種緩衝可以解決任何的業務情境或者資料類型,

如果這種技術出現了,那架構師就又更不值錢了.呵呵.

OSCache
  
  OSCache是個一個廣泛採用的高效能的J2EE緩衝架構,OSCache能用於任何Java應用程式的普通的緩衝解決方案。
  
  OSCache有以下特點:
  
  緩衝任何對象,你可以不受限制的緩衝部分jsp頁面或HTTP請求,任何java對象都可以緩衝。
  
  擁有全面的API--OSCache API給你全面的程式來控制所有的OSCache特性。
  
  永久緩衝--緩衝能隨意的寫入硬碟,因此允許昂貴的建立(expensive-to-create)資料來保持緩衝,甚至能讓應用重啟。
  
  支援叢集--叢集快取資料能被單個的進行參數配置,不需要修改代碼。
  
  緩衝記錄的到期--你可以有最大限度的控制緩衝對象的到期,包括可插入式的重新整理策略(如果預設效能不需要時)。
  
  官方網站 http://www.opensymphony.com/oscache/
  
  Java Caching System 
  
  JSC(Java Caching System)是一個用分布式的緩衝系統,是基於伺服器的java應用程式

。它是通過提供管理各種動態快取資料來加速動態web應用。
  
  JCS和其他緩衝系統一樣,也是一個用於高速讀取,低速寫入的應用程式。
  
  動態內容和報表系統能夠獲得更好的效能。
  
  如果一個網站,有重複的網站結構,使用間歇性更新方式的資料庫(而不是連續不斷的更新資料庫),

被重複搜尋出相同結果的,就能夠通過執行緩衝方式改進其效能和伸縮性。
  
  官方網站 http://jakarta.apache.org/turbine/jcs/
  
  EHCache 
  
  EHCache 是一個純java的在進程中的緩衝,它具有以下特性:快速,簡單,

為Hibernate2.1充當可插入的緩衝,最小的依賴性,全面的文檔和測試。
  
  官方網站 http://ehcache.sourceforge.net/
  
  JCache 
  
  JCache是個開來源程式,正在努力成為JSR-107開源規範,JSR-107規範已經很多年沒改變了。

這個版本仍然是構建在最初的功能定義上。
  
  官方網站 http://jcache.sourceforge.net/
  
  ShiftOne 
  
  ShiftOne Java Object Cache是一個執行一系列嚴格的對象緩衝策略的Java lib,

就像一個輕量級的配置緩衝工作狀態的架構。
  
  官方網站 http://jocache.sourceforge.net/
  
  SwarmCache 
  
  SwarmCache是一個簡單且有效分布式緩衝,它使用IP multicast與同一個區域網路的其他主機進行通訊,

是特別為叢集和資料驅動web應用程式而設計的。SwarmCache能夠讓典型的讀操作大大超過寫操作的這類應用提供更好的效能支援。
  
  SwarmCache使用JavaGroups來管理從屬關係和分布式緩衝的通訊。
  
  官方網站 http://swarmcache.sourceforge.net
  
  TreeCache / JBossCache 
  
  JBossCache是一個複製的交易處理緩衝,它允許你緩衝企業級應用資料來更好的改善效能。

快取資料被自動複製,讓你輕鬆進行JBoss伺服器之間的叢集工作。

JBossCache能夠通過JBoss應用服務或其他J2EE容器來運行一個MBean服務,當然,它也能獨立運行。
  
  JBossCache包括兩個模組:TreeCache和TreeCacheAOP。
  
  TreeCache --是一個樹形結構複製的交易處理緩衝。
  
  TreeCacheAOP --是一個“物件導向”緩衝,它使用AOP來動態管理POJO(Plain Old Java Objects)
  
  註:AOP是OOP的延續,是Aspect Oriented Programming的縮寫,意思是面向方面編程。
  
  官方網站 http://www.jboss.org/products/jbosscache
  
  WhirlyCache 
  
  Whirlycache是一個快速的、可配置的、存在於記憶體中的對象的緩衝。

它能夠通過緩衝對象來加快網站或應用程式的速度,否則就必須通過查詢資料庫或其他代價較高的處理常式來建立。


2.設計模式都知道哪些?什麼是單例模式?怎樣用單例模式實現讀取xxx.properties檔案的內容?

一般模式有4個基本要素:模式名稱(pattern name)、問題(problem)、解決方案(solution)、效果(consequences)。

建立型模式用來處理對象的建立過程,主要包含以下5種設計模式:
                                        Factory 方法模式(Factory Method Pattern)
                                        抽象原廠模式(Abstract Factory Pattern)                                              

                                             提供一個建立一系列相關或相互依賴對象的介面,而無需指定它們具體的類。

                                        建造者模式(Builder Pattern)
                                        原型模式(Prototype Pattern)
                                        單例模式(Singleton Pattern)
 結構型模式用來處理類或者對象的組合,主要包含以下7種設計模式:
        適配器模式(Adapter Pattern)             

             將一個類的介面轉換成客戶希望的另外一個介面。適配器模式使得原本由於介面不相容而不能一起工作的類可以一起工作。

        橋接模式(Bridge Pattern)

             將抽象部分與它的實現部分分離,使它們都可以獨立地變化。

        組合模式(Composite Pattern)       

            將一個複雜物件的構建與它的表示分離,使同樣的構建過程可以建立不同的表示。

        裝飾者模式(Decorator Pattern)
        面板模式(Facade Pattern)
        享元模式(Flyweight Pattern)
        代理模式(Proxy Pattern)
行為型模式用來對類或對象怎樣互動和怎樣分配職責進行描述,主要包含以下11種設計模式:
        責任鏈模式(Chain of Responsibility Pattern)

         為解除請求的寄件者和接收者之間耦合,而使多個對象都有機會處理這個請求。將這些對象連成一條鏈,

並沿著這條鏈傳遞該請求,直到有一個            對象處理它。

        命令模式(Command Pattern)
          將一個請求封裝為一個對象,從而可用不同的請求對客戶進行參數化;對請求排隊或記錄請求日誌,
以及支援可取消的操作。
        解譯器模式(Interpreter Pattern)
        迭代器模式(Iterator Pattern)
        中介者模式(Mediator Pattern)
        備忘錄模式(Memento Pattern)
        觀察者模式(Observer Pattern)
        狀態模式(State Pattern)
        策略模式(Strategy Pattern)
        模板方法模式(Template Method Pattern)
        訪問者模式(Visitor Pattern)

Java開發下的設計模式簡單說明

  設計模式:一個設計模式描述了一個被證實可行的方案。這些方案非常普遍,是具有完整定義的最常用的模式。一般模式有4個基本要素:模式名稱(pattern name)、問題(problem)、解決方案(solution)、效果(consequences)。

  常見23種模式概述:

  1) 抽象原廠模式(Abstract Factory):提供一個建立一系列相關或相互依賴對象的介面,而無需指定它們具體的類。

  2) 適配器模式(Adapter):將一個類的介面轉換成客戶希望的另外一個介面。適配器模式使得原本由於介面不相容而不能一起工作的類可以一起工作。

  3) 橋樑模式(Bridge):將抽象部分與它的實現部分分離,使它們都可以獨立地變化。

  4) 建造模式(Builder):將一個複雜物件的構建與它的表示分離,使同樣的構建過程可以建立不同的表示。

  5) 責任鏈模式(Chain of Responsibility):為解除請求的寄件者和接收者之間耦合,而使多個對象都有機會處理這個請求。將這些對象連成一條鏈,並沿著這條鏈傳遞該請求,直到有一個對象處理它。

  6) 命令模式(Command):將一個請求封裝為一個對象,從而可用不同的請求對客戶進行參數化;對請求排隊或記錄請求日誌,以及支援可取消的操作。

  7) 合成模式(Composite):將對象組合成樹形結構以表示“部分-整體”的階層。它使得客戶對單個對象和綜合物件的使用具有一致性。

  8) 裝飾模式(Decorator):動態地給一個對象添加一些額外的職責。就擴充功能而言,它能產生子類的方式更為靈活。

  9) 門面模式(Facade):為子系統中的一組介面提供一個一致的介面,門面模式定義了一個高層介面,這個介面使得這一子系統更加容易使用。

  10) Factory 方法(Factory Method):定義一個用於建立對象的介面,讓子類決定將哪一個類執行個體化。Factory Method 使一個類的執行個體化延遲到其子類。

  11) 享元模式(Flyweight):運用共用技術以有效地支援大量細粒度的對象。

  12) 解譯器模式(Interpreter):給定一個語言,定義它的文法的一種表示,並定義一個解譯器,該解譯器使用該表示解釋語言中的句子。

  13) 迭代子模式(Iterator):提供一種方法順序訪問一個彙總對象中的各個元素,而又不需暴露該對象的內部表示。

  14) 調停者模式(Mediator):用一個中介對象來封裝一系列的對象互動。中介者使各對象不需要顯式的內部表示。

  15) 備忘錄模式(Memento):在不破壞封裝性的前提下,捕獲一個對象的內部狀態,並在該對象之外儲存這個狀態。這樣以後就可將該對象恢複到儲存的狀態。

  16) 觀察者模式(Observer):定義對象間的一種一對多的依賴關係,以便當一個對象的狀態發生改變時,所有依賴於它的對象都得到通知並自動重新整理。

  17) 原始模型模式(Prototype):用原型執行個體指定建立對象的種類,並且通過拷貝這個原型建立新的對象。

  18) 代理模式(Proxy):為其他對象提供一個代理以控制對這個對象的訪問。

  19) 單例模式(Singleton):保證一個類僅有一個執行個體,並提供一個訪問它的全域訪問點。

  20) 狀態模式(State):允許一個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了它所屬的類。

  21) 策略模式(Strategy):定義一系列的演算法,把它們一個個封裝起來,並且使它們可相互替換。本模式使得演算法的變化可獨立於使用它的客戶。

  22) 模板模式(Template Method):定義一個操作中的演算法的骨架,而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟。

  23) 訪問者模式(Visitor):表示一個作用於某對象結構中的各元素的操作。該模式可以實現在不改變各元素的類的前提下定義作用於這些元素的新操作。


3.SSH或者S2SH整合的步驟?
4.什麼是事務?它有哪些特點?
5.觸發器和預存程序熟嗎?用過它們嗎?怎樣最佳化資料庫?
6.10&8等於幾?
7.怎樣將一個十進位的數轉化成二進位?
8.資料結構學得咋樣?二叉樹中怎樣求其高度?
9.談談自己未來幾年的職業規劃?
10.同事們怎麼評價你在工作中的表現?你怎麼看?
11.你的優缺點是什嗎?

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.