最近“全網(wǎng)域（Web Scale）”一詞被炒得火熱，人們也正在通過擴(kuò)展他們的應(yīng)用程序架構(gòu)來使他們的系統(tǒng)變得更加“全網(wǎng)域”。但是究竟什么是全網(wǎng)域？或者說如何確保全網(wǎng)域？

成都創(chuàng)新互聯(lián)專業(yè)網(wǎng)站設(shè)計(jì)、做網(wǎng)站，集網(wǎng)站策劃、網(wǎng)站設(shè)計(jì)、網(wǎng)站制作于一體，網(wǎng)站seo、網(wǎng)站優(yōu)化、網(wǎng)站營銷、軟文發(fā)稿等專業(yè)人才根據(jù)搜索規(guī)律編程設(shè)計(jì)，讓網(wǎng)站在運(yùn)行后，在搜索中有好的表現(xiàn)，專業(yè)設(shè)計(jì)制作為您帶來效益的網(wǎng)站！讓網(wǎng)站建設(shè)為您創(chuàng)造效益。擴(kuò)展的不同方面

全網(wǎng)域被炒作的最多的是擴(kuò)展負(fù)載（Scaling load），比如支持單個用戶訪問的系統(tǒng)也可以支持10 個、100個、甚至100萬個用戶訪問。在理想情況下，我們的系統(tǒng)應(yīng)該保持盡可能的“無狀態(tài)化（stateless）”。即使必須存在狀態(tài)，也可以在網(wǎng)絡(luò)的不同處理終端上轉(zhuǎn)化并進(jìn)行傳輸。當(dāng)負(fù)載成為瓶頸時候，可能就不會出現(xiàn)延遲。所以對于單個請求來說，耗費(fèi)50到100毫秒也是可以接受的。這就是所謂的橫向擴(kuò)展（Scaling out）。

擴(kuò)展在全網(wǎng)域優(yōu)化中的表現(xiàn)則完全不同，比如確保成功處理一條數(shù)據(jù)的算法也可成功處理10條、100條甚至100萬條數(shù)據(jù)。無論這種度量類型是是否可行，事件復(fù)雜度（大O符號）是最佳描述。延遲是性能擴(kuò)展殺手。你會想盡辦法將所有的運(yùn)算處理在同一臺機(jī)器上進(jìn)行。這就是所謂的縱向擴(kuò)展（Scaling up）。

如果天上能掉餡餅的話（當(dāng)然這是不可能的），我們或許能把橫向擴(kuò)展和縱向擴(kuò)展組合起來。但是，今天我們只打算介紹下面幾條提升效率的簡單方法。

大O符號

Java 7的 ForkJoinPool 和Java8 的并行數(shù)據(jù)流（parallel Stream） 都對并行處理有所幫助。當(dāng)在多核處理器上部署Java程序時表現(xiàn)尤為明顯，因所有的處理器都可以訪問相同的內(nèi)存。

所以，這種并行處理較之在跨網(wǎng)絡(luò)的不同機(jī)器上進(jìn)行擴(kuò)展，根本的好處是幾乎可以完全消除延遲。

但不要被并行處理的效果所迷惑！請謹(jǐn)記下面兩點(diǎn)：

• 并行處理會吃光處理器資源。并行處理為批處理帶來了極大的好處，但同時也是非同步服務(wù)器（如HTTP）的噩夢。有很多原因可以解釋，為什么在過去的幾十年中我們一直在使用單線程的Servlet模型。并行處理僅在縱向擴(kuò)展時才能帶來實(shí)際的好處。
• 并行處理對算法復(fù)雜度沒有影響。如果你的算法的時間復(fù)雜度為 O(nlogn)，讓算法在 c 個處理器上運(yùn)行，事件復(fù)雜度仍然為 O(nlogn/c)， 因?yàn)?c 只是算法中的一個無關(guān)緊要的常量。你節(jié)省的僅僅是時鐘時間（wall-clock time），實(shí)際的算法復(fù)雜度并沒有降低。

降低算法復(fù)雜度毫無疑問是改善性能最行之有效的辦法。比如對于一個 HashMap 實(shí)例的 lookup() 方法來說，事件復(fù)雜度 O(1) 或者空間復(fù)雜度 O(1) 是最快的。但這種情況往往是不可能的，更別提輕易地實(shí)現(xiàn)。

如果你不能降低算法的復(fù)雜度，也可以通過找到算法中的關(guān)鍵點(diǎn)并加以改善的方法，來起到改善性能的作用。假設(shè)我們有下面這樣的算法示意圖：

該算法的整體時間復(fù)雜度為 O(N3)，如果按照單獨(dú)訪問順序計(jì)算也可得出復(fù)雜度為 O(N x O x P)。但是不管怎樣，在我們分析這段代碼時會發(fā)現(xiàn)一些奇怪的場景：

• 在開發(fā)環(huán)境中，通過測試數(shù)據(jù)可以看到：左分支（N->M->Heavy operation）的時間復(fù)雜度 M 的值要大于右邊的 O 和 P，所以在我們的分析器中僅僅看到了左分支。
• 在生產(chǎn)環(huán)境中，你的維護(hù)團(tuán)隊(duì)可能會通過 AppDynamics、DynaTrace 或其它小工具發(fā)現(xiàn)，真正導(dǎo)致問題的罪魁禍?zhǔn)资怯曳种В∟ -> O -> P -> Easy operation or also N.O.P.E.）。

在沒有生產(chǎn)數(shù)據(jù)參照的情況下，我們可能會輕易的得出要優(yōu)化“高開銷操作”的結(jié)論。但我們做出的優(yōu)化對交付的產(chǎn)品沒有起到任何效果。

優(yōu)化的金科玉律不外乎以下內(nèi)容：

• 良好的設(shè)計(jì)將會使優(yōu)化變得更加容易。
• 過早的優(yōu)化并不能解決多有的性能問題，但是不良的設(shè)計(jì)將會導(dǎo)致優(yōu)化難度的增加。

理論就先談到這里。假設(shè)我們已經(jīng)發(fā)現(xiàn)了問題出現(xiàn)在了右分支上，很有可能是因產(chǎn)品中的簡單處理因耗費(fèi)了大量的時間而失去響應(yīng)（假設(shè)N、O和 P 的值非常大）， 請注意文章中提及的左分支的時間復(fù)雜度為 O(N3)。這里所做出的努力并不能擴(kuò)展，但可以為用戶節(jié)省時間，將困難的性能改善推遲到后面再進(jìn)行。

這里有10條改善Java性能的小建議：

1、使用StringBuilder

StingBuilder 應(yīng)該是在我們的Java代碼中默認(rèn)使用的，應(yīng)該避免使用 + 操作符。或許你會對 StringBuilder 的語法糖（syntax sugar）持有不同意見，比如：

String x = "a" + args.length + "b";

文章題目：10種簡單的Java性能優(yōu)化-創(chuàng)新互聯(lián)
鏈接URL：http://www.yijiale78.com/article44/idshe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、手機(jī)網(wǎng)站建設(shè)、電子商務(wù)、網(wǎng)站導(dǎo)航、用戶體驗(yàn)、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)