1、java, 高并發(fā)解決方案篇一： Java 高并發(fā)程序設(shè)計Java 高并發(fā)程序設(shè)計第一課前沿? 在計算密集型的領(lǐng)域中非常適用并行程序? 多核 CPU 的產(chǎn)生促使了并行程序的設(shè)計，摩爾定律的失效，芯片的性能不能提高，4GHz 已經(jīng)是當(dāng)下最高的頻率，從而產(chǎn)生多核CPU 的出現(xiàn)。? 活鎖 ： 兩個資源A、 B， 進程 1 和 2 分別占用A和 B時發(fā)現(xiàn)不能工作，就同時釋放掉，然后又同時分別占用B和 A 如此反復(fù)！出現(xiàn)活鎖? 阻塞：第二課 Java 并行程序基礎(chǔ)? 線程是比進程更細粒度的執(zhí)行單元，可以說是屬于進程的一個子集?7,Thread 類的 run()方法實現(xiàn)于Runnable 接口，如果直接調(diào)

2、用run()方法，不會啟動新的線程，而是在當(dāng)前線程下運行， start() 方法會開啟一個新的線程。兩種方式，1 重載 run 方法2，實現(xiàn)Ruanable 接口8, Thread.Interrupt() 是一種比較的讓線程終止的方法優(yōu)雅的方法， 不會立刻停止掉該程序， 根據(jù)程序的設(shè)計，而是根據(jù)該程序的設(shè)計，當(dāng)執(zhí)行完該程序的一次循環(huán)之后，在下次循環(huán)程序開始之前中斷，保證該程序的數(shù)據(jù)完整性。9， try Thread.sleep(2000); catch (InterruptedException e) / 設(shè) 置 中 斷 狀 態(tài) ， 拋 出 異 常 后 會 清 除 中 斷 標(biāo) 記 位e.pri

3、ntStackTrace(); 10，查看當(dāng)前被掛起的進程命令jps查看進程中具體線程的信息jstack 588011，? 等待線程結(jié)束join(),其本質(zhì)是判斷線程是否還存活，如果一直存活那么通知調(diào)用該線程的其他線程等待，如果結(jié)束有JVM 調(diào)用notifyAll() 喚醒所有等待該線程的線程。f (millis = 0) while (isAlive() wait(0);12 ，守護線程在后臺默默的完成一些系統(tǒng)性的服務(wù)，比如垃圾回收與JIT 線程等。但非守護線程結(jié)束時，JVM 不會因為守護線程而繼續(xù)執(zhí)行，隨之而推出。13 ， 線程優(yōu)先級的運行時候只是在概率上發(fā)生的可能下要大！14， sync

4、hronized 加鎖的三種方式。? 對象實例加鎖? 實例方法加鎖? 類級別實例方法加鎖謙讓 yield()第三課 Java 內(nèi)存模型和線程安全? 同一個操作在兩條不同的指令之間是不能夠一起做的，因為他們會使用同一個硬件設(shè)備 .? 可見性問題是各個層面優(yōu)化產(chǎn)生的? Java 并原子性 發(fā)編程的的三個重要的概念。可見性 有序性，并發(fā)程序會發(fā)生指令重排，導(dǎo)致語句執(zhí)行順序發(fā)生變化的情況，雖然處理器會對指令進行重排序，但指令是它會保證程序最終結(jié)果會和代碼順序執(zhí)行結(jié)果相同；重排序不會影響單個線程的執(zhí)行，但是會影響到線程并發(fā)執(zhí)行的正確性。? 要想并發(fā)程序正確地執(zhí)行，必須要保證原子性、可見性以及有序性。只要

5、有一個沒有被保證，就有可能會導(dǎo)致程序運行不正確。第四課無鎖? 無鎖的性能要遠好于阻塞的執(zhí)行方式? 前導(dǎo)零 是指 轉(zhuǎn)換成二進制的時候前面為零的個數(shù)( LeadingZeros)? 無鎖實現(xiàn)Stack 堆棧，見作業(yè)第五課 JDK 并發(fā)包 11. Reentrantlock 是屬于 Synchronized 的增強版，多增加了一些特有的功能2. ConcurrentHashMap 屬于高并發(fā)的解決方案3. HashMap 發(fā)生大量沖突的時候，會退化成一個鏈表，引起性能降低4. BlockingQueue 阻塞隊列，會引起線程的阻塞，不是一個高性能的并發(fā)實現(xiàn)，內(nèi)部實現(xiàn)機制采用了加鎖，同時只有一個線程進

6、入第六課 JDK 并發(fā)包 21， 線程池實現(xiàn)了對線程的復(fù)用，避免了線程的多次創(chuàng)建和銷毀，節(jié)省了 CPU 處理時間。2，Java 內(nèi)置線程池，Callable 與 Runnable 的區(qū)別是有無返回值3，F(xiàn)orkJoinPool 說明該線程池是如何工作的第七課設(shè)計模式1, 采 用 靜 態(tài) 內(nèi) 部 類 來 實 現(xiàn) 單 例 模 式 ， 可 以 保 證 在StaticSingleton 類中只調(diào)用getInstance()方法時才會初始化類，從而保證了在操作該類其他字段的時候，不會被初始 化。 篇二： ActiveMQ 高并發(fā)處理方案 高并發(fā)發(fā)送消息異常解決方法：現(xiàn)象：使用10 個線程每100ms 發(fā)

7、送一條消息，大約3000 多條后，出現(xiàn)異常，所有線程停止： javax.jms.JMSException: Could not connectto brokerURL:tcp:/localhost:61616.Reason:.BindException: Address already in use: connect; nested exception is.BindException: Address already in use: connect原因：創(chuàng)建了太多jms 連接沒有來得及回收解決方法：使用jms 連接池原來的配置：<bean <property na

8、me=environment<props<prop key=java.naming.factory.initialorg.apache.activemq.jndi.ActiveMQInitialContextFactory</prop<propkey=vider.urltcp:/huzq-linux:61616</prop </props </property</bean<bean<property name=jndiName

9、<valueConnectionFactory</value</property<property name=jndiTemplate<ref local=jndiTemplate</ref</property</bean修改為：解決 activemq 多消費者并發(fā)處理遇到一個現(xiàn)象，如果activemq 隊列積壓了數(shù)據(jù)的話，如果在 spring 中啟動listner，只有一個consumer執(zhí)行，查閱了很多資料，無果，后來偶爾通過activemq 的監(jiān)控網(wǎng)頁看到消費者列表中，只有一個

10、消費者有等待處理的數(shù)據(jù)，其他都沒有，如下圖：由此得知，activemq 有一定機制將隊列中的數(shù)據(jù)交給consumer 處理，這個機制就是數(shù)據(jù)的數(shù)量分配，查資料得知，默認是1000，因此，把這個值調(diào)小就可以了。在 客 戶 端 的 連 接 url 中 ， 修 改 為tcp:/ipaddr:61616?jms.prefetchPolicy.all=2這樣基本消費者就分配公平了，不會出現(xiàn)一個消費者忙死，另外的消費者閑死了。為高并發(fā)程序部署ActiveMQ使用 ActiveMQ 來擴展你的應(yīng)用程序需要一些時間并要花一些精力.本節(jié)中我們將介紹三種技術(shù)用于擴展應(yīng)用程序.我們將從垂直擴展開始,這種擴展方式中,

11、單個代理需要處理成千上萬的連接和消息隊列.接下來我們將介紹水平擴展,這種擴展方式需要處理比前一種方式更多的網(wǎng)絡(luò)連接.最后,我們介紹的傳輸負載分流,可以在擴展和性能間得到平衡,但是會增加ActiveMQ 程序的復(fù)雜性 .1. 垂直擴展:垂直擴展是一種用于增加單個ActiveMQ 代理連接數(shù)（因而也增加了負載能力）的技術(shù).默認情況下,ActiveMQ 的被設(shè)計成盡可高效的傳輸消息以確保低延遲和良好的性能.但是,你也可以進行一些配置使的ActiveMQ 代理可以同時處理大量并發(fā)的連接以及大量的消息隊列.默認情況下,ActiveMQ 使用阻塞IO 來處理傳輸連接,這種方式為每一個連接分配一個線程.你可

12、以為ActiveMQ 代理使用非阻塞IO（ 同時客戶端可以使用默認的傳輸）以減少線程的使用.可以在ActiveMQ 的配置文件中通過傳輸連接器配置非阻塞IO. 下面的是配置非阻塞IO 的示例代碼：配置NIO 傳輸連接器除了為每個連接使用一個線程的阻塞IO,ActiveMQ 還可以為每一個客戶端連接使用一個消息分發(fā)線程.你可以通過將系統(tǒng)參數(shù)org.apache.activemq.UseDedicatedTaskRunner 設(shè)置為 false來設(shè)置ActiveMQ 使用一個搞線程池.下面是一個示例:確保 ActiveMQ 代理用于足夠的內(nèi)存來處理大量的并發(fā)連接 ,需要分兩步進行:首先,你需要確保

13、運行ActiveMQ 的 JVM 在啟動之前已經(jīng)配置了足夠的內(nèi)存.可以使用JVM 的-Xmx 選項來配置,如下所示:其次,需要確保JVM 配置了適量的專門供ActiveMQ 代理使用的內(nèi)存.這個配置可用通過<system-Usage 元素的 limit屬性來配置.一個不錯的根據(jù)經(jīng)驗得到的規(guī)則時,在連接數(shù)為幾百個時配置512MB 為最小內(nèi)存.如果測試發(fā)現(xiàn)內(nèi)存不夠用,可以增加內(nèi)存配置.你可以按照下面代碼示例來配置ActiveMQ 使用的內(nèi)存限制:代碼:為ActiveMQ 代理設(shè)置內(nèi)存使用限制同樣,簡易減少每個連接的CPU負 載 .如果你正使 用 Open-Wire 格 式 的消 息

14、,關(guān) 閉 tightencoding 選項,開啟該選項會導(dǎo)致CPU 占有過多.Tightencoding 選項可以通過客戶端連接的URI 中的參數(shù)設(shè)置以便關(guān)閉該選項.下面是示例代碼:了解了一些擴展ActiveMQ 代理處理大量連接的調(diào)優(yōu)選項之后,我們在了解一些讓ActiveMQ 處理大量消息隊列的調(diào)優(yōu)選項 .默認的消息隊列配置中使用一個獨立的線程負責(zé)將消息存儲中的消息提取到消息隊列中而后再被分發(fā)到對其感興趣的 消 息 消 費 者 .如 果 有 大 量 的 消 息 隊 列 ,建 議 通 過 啟 用 optimizeDispatch 這個屬性改善這個特性,示例代碼如下所示:注意,代碼清單中使用通配

15、符表示該配置會遞歸的應(yīng)用到所有的消息隊列中.為確保擴展配置既可以處理大量連接也可以處理海量消息隊列,請使用JDBC 或更新更快的KahaDB 消息存儲.默認情況下 ActiveMQ 使用 KahaDB 消息存儲.到目前位置,我們關(guān)注了連接數(shù)擴展,減少線程使用以及選擇正確的消息存儲.下面的示例配置代碼展示了ActiveMQ配置中為擴展進行了調(diào)優(yōu):代 碼 ： 為 擴 展 進 行 調(diào) 優(yōu) 的 配 置 示 例 代 碼 <broker xmlns=/schema/core brokerName=amq-brokerdataDirectory

16、=$activemq.base/data<persistenceAdapter<kahaDBdirectory=$activemq.base/data journalMaxFileLength=32mb/ </persistenceAdapter <destinationPolicy <policyMap <policyEntries <policyEntryqueue= optimizedDispatch=true/</policyEntries</policyMap

17、 </destinationPolicy<systemUsage<systemUsage <memoryUsage<memoryUsagelimit=512 mb/ </memoryUsage<storeUsage <storeUsage limit=10 gb name=foo/ </storeUsage <tempUsage <tempUsage limit=1 gb/ </tempUsage </system

18、Usage </systemUsage 篇三：大型互聯(lián)網(wǎng)站解決高并發(fā)的常見策略大型互聯(lián)網(wǎng)站解決高并發(fā)的常見策略作者 : H.E. | 您可以轉(zhuǎn)載, 但必須以超鏈接形式標(biāo)明文章原始出處和作者信息及版權(quán)聲明網(wǎng)址 :/article/high-concurrent-common-coping-strategies.html 豆 瓣 讀 書 向 你 推 薦 有 關(guān) Hadoop、 J2ee 企 業(yè) 顧 問 、 Linux/Unix 、 MapReduce、 NoSQL 、 web、云計算、分布式、存儲、性能、架構(gòu)設(shè)計、類別的圖書。一個運營的系統(tǒng)在正式上線后將會遇到各種層級的高并發(fā)請求，因

19、此我們必須對此做出相應(yīng)的策略和技術(shù)解決方案，首先我們需要認清系統(tǒng)的高并發(fā)由3 個層面導(dǎo)致：1. 傳輸層大量用戶對系統(tǒng)請求后，將會造成網(wǎng)絡(luò)帶寬和Web 服務(wù)器的 I/O 瓶頸。2. 計算層接收大量用戶請求進行計算，將會造成業(yè)務(wù)服務(wù)器和業(yè)務(wù)支撐服務(wù)器的瓶頸。3. 存儲層傳輸層和計算層將會產(chǎn)生大量的數(shù)據(jù)，數(shù)據(jù)量暴增，將會導(dǎo)致數(shù)據(jù)庫和儲存上的瓶頸。針對以上將會造成的系統(tǒng)高并發(fā)瓶頸，我們需要采用不同的技術(shù)手段解決。從總體上來看1 . 首先需要解決網(wǎng)絡(luò)帶寬和Web 請求的高并發(fā)，需要合理的加大服務(wù)器和帶寬的投入，并且需要充分的利用系統(tǒng)中軟件、硬件的緩存機制，將能緩存的內(nèi)容都進行緩存存儲，減少計算層和存儲層

20、的壓力。2 .其次需要對業(yè)務(wù)服務(wù)器和業(yè)務(wù)支撐服務(wù)器進行合理的分層，并且采用并行計算和分布式算法對大量計算進行處理，并 且 在 開 發(fā) 的 過 程 中 需 要 采 用 Java SDK 中 并 發(fā) 包 (Concurrency)進行編碼實現(xiàn)。3 .存儲層需要采用分布式文件服務(wù)器和列式的存儲服務(wù)器進行構(gòu)建，支撐海量數(shù)據(jù)的存放和讀取，并且還要對關(guān)系型數(shù)據(jù)進行深層次的配置參數(shù)優(yōu)化。4 .我們還需要清楚的認識到，將來根據(jù)系統(tǒng)運行的狀態(tài)以及平臺中不同的業(yè)務(wù)場景循序漸進的進行調(diào)整和優(yōu)化。對于大型系統(tǒng)來說，采用的技術(shù)是涉及面非常廣，從硬件到軟件、編程語言、數(shù)據(jù)庫、WebServer、防火墻等各個領(lǐng)域都有了很高

21、的要求。在面對大量用戶訪問、高并發(fā)請求方面，基本的解決方案集中在這樣幾個環(huán)節(jié)：將會使用高性能的服務(wù)器、高性能的數(shù)據(jù)庫、高效率的編程語言、還有高性能的Web 容器。但是除了這幾個方面，還沒法根本解決面臨的高負載和高并發(fā)問題，所以需要將計算和負載的壓力分載到每個計算機上，使用不同的服務(wù)器集群機組進行分布式和并行計算，面對所產(chǎn)生的壓力，下面這張圖清晰的描述了，我們對系統(tǒng)中不同的計算瓶頸采用的不同解決手段，如圖所示：查看大圖請點擊這里以下描述是針對不同層面產(chǎn)生的計算壓力所采用的計算策略，清單如下：傳輸層通過 CDN 讓用戶訪問最近的1. CDN網(wǎng)絡(luò)鏈路出口進行壓力分載，數(shù)據(jù)緩存。2. 智能雙路針對電信、網(wǎng)通不同的訪問用戶訪問請求，對應(yīng)用戶訪問請求進行服務(wù)器帶寬的智能切換。3. LVS對用戶的請求進行壓力分載，并且實現(xiàn)多種負載均衡的策略，也可以選擇使用HA-Proxy 實現(xiàn)。4. HA-Pr