原创 java線程池深入一

一.目的 多線程並行,提升效率,線程重用,減少創建線程開銷。 二.基礎知識 線程池幾個核心要素: 1.核心線程數 當有新的任務進來時,若沒有超過這個核心線程數,則會創建新的線程來執行任務。 2.最大線程數 用於限制最多可創建的線程,若

原创 netty PoolChunk內存分配一

目的: 申請的內存可重用,比如直接內存。 netty抽象了一個poolChunk,用於管理申請的物理內存。一個PollChunk默認16M,但是申請內存時有可能小於這個值,因此netty將poolChunk進行切分。分成若干個subPag

原创 dubbo處理調用請求涉及緩存問題

一.場景 dubbo底層使用netty,一個boss線程,核心線程+1個worker。 讀寫io在worker線程去做。 每個worker會處理一部分socket讀寫。 高併發時,io線程不太會不足,原因是默認是核心線程+1。高併發時每個

原创 cms垃圾回收

以下講的是cms標記清除垃圾回收算法。 http://www.w2bc.com/article/258496 https://github.com/pzxwhc/MineKnowContainer/issues/89 一.目的 大量存

原创 業務訂單分庫分表二-擴容

一.原先業務訂單情況 2個物理表, order_0000,order_0032 每個分組32個邏輯分表 原先元素分佈: 邏輯分表號:0-31 在order_0000,32-63在order_0032 物理分表名=邏輯分表號/32%3

原创 mysql事務簡述

底層基於redo, undo日誌來做。 undo用於回滾,redo用於down機後恢復數據 redo物理文件名:ib_logfile0和ib_logfile1 eg: 將庫存skuStore從1改成2,假設事務號爲:x需要做的事情如

原创 dubbo調優

http://alibaba.github.io/dubbo-doc-static/Dubbo+Protocol-zh.htm http://dubbo.io/user-guide/demos/%E5%B9%B6%E5%8F%91%

原创 業務訂單分表一

目的: 分庫分表,通常在數據量增加,將會使得讀寫性能下降時,數據分散的一種策略。 通常分庫分表,有兩種選擇,一種是垂直,一種是水平。 垂直一般按業務領域劃分,比如用戶,訂單,產品等。 水平則是將將單個業務領域某一業務實體的數據按某種維度進

原创 jvm垃圾回收-標記複製

一.目的 與標記清除相比,不會產生內存碎片。 二.適用場景 對象生命週期短,適合新生代。 三.基本流程 整個jvm堆分爲年輕代,老年代,永久代。 其中年輕代被分成:eden,s0,s1 默認大小比例是:8:1:1。 即能夠保證在分

原创 工作反思170608

工作上的技術方案,最好什麼時間點做什麼事情,誰負責,相應預案是什麼,前提條件是什麼都需要寫好。即上線流程。 相應的與產品問題確認,或任何其他人的問題確認,都走郵件。 要有灰度測試期間,在這個期間只對內部用戶生效,測試可以在此期間發現問

原创 spring事務整理一

工作很多年了,整理下自己的知識體系。 spring爲了方便事務管理,提供了註解與xml配置事務的形式。 業務中事務使用時注意點: 1.避免超長事務,影響性能及吞吐量,特別是一般業務在開啓事務時會加數據庫行級鎖,如果事務超長會影響其它事務

原创 dubbo擴展點

  一.目的:    使用者能夠不改dubbo項目的情況下,在應用項目中增加相應類及配置就可以實現擴展。   二.類似jdk的spi,但比jdk spi有以下優勢:   1.jdk的spi默認會加載並實例化所有擴展點類,如果對應擴展點沒

原创 性能優化1-概述

一.性能優化概述 根據不同應用,業務場景及指標的情況下,制定要達到的性能指標。 找到性能問題,然後分析瓶頸,解決性能問題。 通常的瓶頸有:應用層代碼,算法,本身應用架構,數據庫層,jvm等。 常見的指標有: 吞吐量,tps,qps,響應

原创 java線程池深入三-Worker

一.目的 Worker用於執行任務。 順便了解下線程池狀態流: running可以通過shutdown方法到shutdown狀態,然後之後會變成tidying狀態,最後變成terminate狀態。 通過shutdownNow方法,則狀態

原创 rocketmq中零拷貝深入

比較好的文章:http://www.linuxjournal.com/article/6345?page=0,2 所謂零拷貝,指的是應用內存與內核內存不存在拷貝。 對應零拷貝技術有mmap及sendfile。 一.mmap優點: 小文