原创 實現聲明式鎖,支持分佈式鎖自定義鎖、SpEL和結合事務

目錄2.實現2.1 定義註解2.2 定義鎖接口2.3 鎖的實現2.3.1 什麼是SPI2.3.2 通過SPI實現鎖的多個實現類2.3.3 通過SPI自定義實現鎖3.定義切面3.1 切面實現3.2 SpEL表達式獲取動態key3.3 鎖與事務

原创 分享一個生產者-消費者的真實場景

0.背景 現在有一個大數據平臺,我們需要通過spark對hive裏的數據讀取清洗轉換(etl)再加其它的業務操作的過程,然後需要把這批數據落地到tbase數據庫(騰訊的一款分佈式數據庫)。 數據導入的特點是不定時,但量大。每次導入的數據量在

原创 來自jackson的靈魂一擊:@ControllerAdvice就能保證萬無一失嗎?

前幾天寫了篇關於fastjson的文章,《fastjson很好,但不適合我》。裏面探討到關於對象循環引用的序列化問題。作爲spring序列化的最大競品,在討論fastjson的時候肯定要對比一下jackson的。所以我也去測試了一下Jack

原创 fastjson很好,但不適合我

記者:大爺您有什麼特長呀? fastjson:我很快。 記者:23423乘以4534等於多少? fastjson:等於2343. 記者:?? fastjson:你就說快不快吧! 這個略顯馬麗蘇的標題,各位看官將就着看吧。主要是怕被噴。

原创 一次spark任務提交參數的優化

起因 新接觸一個spark集羣,明明集羣資源(core,內存)還有剩餘,但是提交的任務卻申請不到資源。 分析 環境 spark 2.2.0 基於yarn集羣 參數 spark任務提交參數中最重要的幾個: spark-submit --

原创 當transcational遇上synchronized

工作當中經常會遇到既需要開啓事務管理,同時也需要同步保證線程安全的場景。 比如一個方法 @Transactional public synchronized void test(){ // } 不知道大家有沒有這樣寫過? 這樣寫

原创 一個由public關鍵字引發的bug

先來看一段代碼: @Service @Slf4j public class AopTestService { public String name = "真的嗎"; @Retryable public void

原创 記錄一次鎖的優化

項目背景 老規矩,先講講項目背景。可跳過。 小工具類的微系統。 我們會有一些文本語義描述的事件。譬如某小區兩戶人家因爲寵物發生了爭吵,比如某人撥打12345熱線反映小區深夜還在跳廣場舞等等。這些統稱事件。 小學語文老師告訴我們描述事件的敘述

原创 《關於我因爲flink成爲spark源碼貢獻者這件小事》

各位讀者老爺請放下手上的板磚,我可真沒有標題黨,且容老弟慢慢道來。 spark和flink本身相信我不用做過多的介紹,後端同學不管搞沒搞過大數據,應該都多多少少聽過。 如果沒聽過,簡單說,spark和flink之於大數據,就好比vue和r

原创 一次生產環境CPU佔用高的排查

1. 項目背景 甲方是保密級別非常高的政府部門。所以我們全程拿不到任何測試數據,只能是自己模擬數據進行測試。 項目部署的時候,公司派了一人到甲方現場,在甲方客戶全程監督下,進行部署,調試,導入數據等工作。因爲前期看不到真實的數據,所以很多功

原创 【工作隨手記】deaklock排查

生產環境當中還沒真正遇到過死鎖的問題。有些疑似死鎖的問題,後來經過排查也只是其它問題導致的。所以通過jstack到底怎樣排查死鎖問題有點疏忽了。這裏作個記錄。 模擬一個死鎖 順便複習一下。 死鎖的產生有四個必要的條件 互斥使用,即當資源被

原创 hashmap的一些性能測試

目錄0.前言1.準備工作。1.1模擬哈希衝突1.2 java的基準測試。2.測試初始化長度3.模擬一百萬個元素put,get的差異。4.模擬無紅黑樹情況下get效率4.1 將random擴大,哈希衝突嚴重性大大減小,模擬大多數哈希衝突導致的

原创 【工作隨手記】fastjson date格式化驗優先級的問題

本來是一個風和日麗的下午,一個非常簡單的改動需求。接口返回的日期類型只需要年月日不需要時分秒。因爲我的項目json使用的是fastjson,而不是spring自帶的jackson(不要問我爲什麼)。因爲全局格式化爲yyyy-MM-dd HH

原创 【工作隨手記】併發之synchronized

synchronized對於java同學肯定都是耳熟能詳的必修課了。但是不管對於新手還是老手都有一些容易搞錯的點。這裏權做一點記錄。 鎖的是代碼還是對象? 同步塊一般有兩種寫法。 1是直接加以方法體上。 public synchronize

原创 【工作隨手記】mysql優化之1

原SQL: SELECT p.id, p.NAME, p.idcard, p.phone, p.plate, p.FAMILY_NO FROM t_person_info p WHERE p.id IN ( SELECT id FROM