
2015年11月27日
已經一個多月沒有寫東西了,不過最近確實很忙。前兩天在線上碰到一個C3P0的鏈接死鎖的異常,話說這個上古神物 ,我已經是很久不碰了。先貼異常

異常截圖
"apparent deadlocks":名詞解釋是說c3p0拿到鏈接之后,最終使用之后沒有返回到pool,導致死鏈檢測失敗。經過在stack Overflow檢索,https://stackoverflow.com/questions/3730844/c3p0-apparent-deadlock-when-the-threads-are-all-empty.發現增加一個statementCacheNumDeferredCloseThreads該參數的定義,就可以避免這個問題。
經過查看官方文檔:http://www.mchange.com/projects/c3p0/#statementCacheNumDeferredCloseThreads
解釋:如果把該值設為超過1,statement的緩存就會自動跟蹤當前可用的connections,如果沒有再用,就會自動銷毀掉。如果需要另外的線程來專門銷毀緩存的statement,則還需要設置maxStatements與maxStatementsPerConnection。
再貼一個官方的說明:
Configuring Statement Pooling
c3p0 implements transparent PreparedStatement pooling as defined by the JDBC spec. Under some circumstances, statement pooling can dramatically improve application performance. Under other circumstances, the overhead of statement pooling can slightly harm performance. Whether and how much statement pooling will help depends on how much parsing, planning, and optimizing of queries your databases does when the statements are prepared. Databases (and JDBC drivers) vary widely in this respect. It's a good idea to benchmark your application with and without statement pooling to see if and how much it helps.
You configure statement pooling in c3p0 via the following configuration parameters:
maxStatements
maxStatementsPerConnection
statementCacheNumDeferredCloseThreads
maxStatementsis JDBC's standard parameter for controlling statement pooling.maxStatementsdefines the total numberPreparedStatementsa DataSource will cache. The pool will destroy the least-recently-used PreparedStatement when it hits this limit. This sounds simple, but it's actually a strange approach, because cached statements conceptually belong to individual Connections; they are not global resources. To figure out a size formaxStatementsthat does not "churn" cached statements, you need to consider the number offrequently usedPreparedStatements in your application,and multiply that by the number of Connections you expect in the pool (maxPoolSizein a busy application).
maxStatementsPerConnectionis a non-standard configuration parameter that makes a bit more sense conceptually. It defines how many statements each pooled Connection is allowed to own. You can set this to a bit more than the number ofPreparedStatementsyour applicationfrequentlyuses, to avoid churning.
If either of these parameters are greater than zero, statement pooling will be enabled. If both parameters are greater than zero, both limits will be enforced. If only one is greater than zero, statement pooling will be enabled, but only one limit will be enforced.
大概意思就是這兩個,有一個值如果大于0,c3p0的statement pool就會發生作用。
以上所有的配置都是基于c3p0的最新版本。PS一下,還是2015年的JAR。
通過引入最新的C3P0包,另外增加了兩段配置,線上觀察兩天,問題解決。
最后打個小廣告,JAVA世界最快的JDBC連接池,非HikariCP莫屬。已經甩c3p0好幾個街角,有圖有真像。
posted @
2017-11-10 15:25 alexcai 閱讀(1799) |
評論 (0) |
編輯 收藏
摘要: 在word的處理之中,文字,各種類型的圖片,最復雜的公式,之前編寫的API基本都覆蓋了。不過,昨天在做一個文檔測試時,發現表格沒有能很好的處理。
閱讀全文
posted @
2017-08-25 15:54 alexcai 閱讀(757) |
評論 (0) |
編輯 收藏
摘要: HDFS和MapReduce是Hadoop的兩大核心,除此之外Hbase、Hive這兩個核心工具也隨著Hadoop發展變得越來越重要。今天我們只初步的看看HDFS.
閱讀全文
posted @
2017-07-24 10:35 alexcai 閱讀(662) |
評論 (0) |
編輯 收藏
摘要: 使用thrift已經有段時間了,目前基本是clien+server的方式,負載是通過nginx來處理。這種處理方式有兩個比較大的弊端:
閱讀全文
posted @
2017-06-29 16:39 alexcai 閱讀(881) |
評論 (0) |
編輯 收藏
www.taggerin.com,主要處理日常文檔的在線編輯,以及與Markdown,PDF,html等格式的雙向轉換.聽說內測版本已經發布。真正的文檔在線編輯與預覽。?
posted @
2017-06-02 09:45 alexcai 閱讀(707) |
評論 (0) |
編輯 收藏
摘要: 一般的業務開發,不會涉及到多種數據庫類型的操作。因為,無論是對于開發,還是運維,成本都是非常高的。如果是ORACLE數據庫到MYSQL的數據備份,目前我所了解的開源解決方案有2種:
閱讀全文
posted @
2016-12-15 13:33 alexcai 閱讀(1240) |
評論 (0) |
編輯 收藏
摘要: 作為日常支付業務,微信的接入逐漸進入了大家的視野。今天以PC端接入微信支付的基本流程來說明。
閱讀全文
posted @
2016-07-26 11:59 alexcai 閱讀(1443) |
評論 (2) |
編輯 收藏
摘要: 在WORD里面編輯公式,目前是有兩種方法。
閱讀全文
posted @
2016-07-15 08:30 alexcai 閱讀(2195) |
評論 (1) |
編輯 收藏
摘要: 最近在弄項目的壓測,首先想到把應用服務器TOMCAT的相關配置升級,網上看了很多關于TOMCAT升級的案例,于是結合自己的實際情況,做了筆記。
閱讀全文
posted @
2016-07-08 09:50 alexcai 閱讀(1557) |
評論 (2) |
編輯 收藏
摘要: 當我們淡到RPC服務框架,放眼世界范圍,我目前知道的主流有thrift,fingle,grpc等。當然大型互聯網公司都會有自己的RPC服務與治理框架。經過一段時間的調研,本著簡單,高效的原則,最終選擇thrift.具體原因,等接下來寫到服務篇的時候再細說。
閱讀全文
posted @
2016-06-29 18:14 alexcai 閱讀(1528) |
評論 (2) |
編輯 收藏
摘要: 目前公司業務上,有課程直播這一塊。為了增加用戶的互動,需要增加聊天室功能。聊天室,對實時性有較嚴格的要求,所以考慮使用socketio來做。目前在服務端,有基于netty實現的websocketio的框架。https://github.com/mrniko/netty-socketio,這個作者還是挺厲害的(redisson的作者)。
閱讀全文
posted @
2016-06-06 08:37 alexcai 閱讀(3041) |
評論 (2) |
編輯 收藏
摘要: SOLR作為成熟的企業級檢索服務,已經有些年頭。我在5年前,也接觸部分皮毛。當時跟另外一個同事,一起學習學運用到我們的產品之中,當時是面對的數據量是500-700百W,多表聯合處理。然后通過SOLR,引入索引,再走日常的查詢。大概也是在4年前,在入門MVN之后,通過MVN快速搭建了SOLR運行環境,幾天前,又翻看了一下寫的POM,覺得很有必要與大家進行一下REVIEW,溫故而知新!我也對比了當前網上多如牛毛的SOLR搭建文章,總感覺我照著做,還是不會。當然,當時的POM,我是參照了國外一個大牛弄的,當時的SOLR版本是4.4.0.目前SOLR的6版本都出來,不過,需要JDK8以上。鄙人一直在用JDK7,所以,不考慮一下跨那么大,怕扯到蛋了。哈哈,玩笑話。另外由于之前分詞,是用的jcseg,當時的版本也比較舊(1.8.9),所以今天做了相關升級。我就分享一下相關的心得,多有不足,歡迎指正。
環境說明:
閱讀全文
posted @
2016-05-20 18:38 alexcai 閱讀(217) |
評論 (0) |
編輯 收藏
摘要: 本文不涉及太多配置項管理,只是針對小白用戶的最快安裝手冊
閱讀全文
posted @
2016-05-13 10:55 alexcai 閱讀(1611) |
評論 (2) |
編輯 收藏
摘要: 在當前的互聯網類產品中,如何高效可用的生成的一個全局自增ID,是一個比較有挑戰性的工作。我見過的一般的做法其實就是時間戳再加固定長度的隨機 字符串。這個方案其實有兩個問題,一個是生成的自增ID的可讀性,另外就是隨機,并不是真正的唯一,它是一個碰撞概率的。其它方案,如依賴數據的自增 ID,如果多個庫,可以通過不同的步長來實現可讀的序列。不過,這其實性能上肯定不可能很高。另外,會有單點的問題。所以,果斷放棄。在查看了目前比較成 熟的snowfake方案之后,感覺不錯。下圖是它的算法核心
閱讀全文
posted @
2016-04-26 09:22 alexcai 閱讀(2143) |
評論 (0) |
編輯 收藏
摘要: 最近在調研文件的分布式存儲及高可用,在GITHUB上面,發現了這個SeaweedFS項目不錯。
閱讀全文
posted @
2016-04-15 18:55 alexcai 閱讀(2969) |
評論 (4) |
編輯 收藏
摘要: 今天在一個技術群里面,有同學提到了HyperLogLog(數據結構),排序方面技術。所以今天看一下相關的資料,算作一個總結。
閱讀全文
posted @
2016-03-23 17:47 alexcai 閱讀(1088) |
評論 (0) |
編輯 收藏
摘要: docx4j是一款在java世界處理微軟word/ppt/excel文檔的強大工具。它其實是一個半開源的產品。雖然它對WORD各種處理在API層 面進行了封裝,但是像WORD本身的拆分,合并。其作者(Jason Harrop)是單獨提出來了,封裝成了商用的JAR包來提供支持。而我在深入學習其API之后,先后將組合,拆分技術進行了實現。
閱讀全文
posted @
2016-03-14 16:10 alexcai 閱讀(5561) |
評論 (2) |
編輯 收藏
摘要: spring mvc中,變量有一個作用域的概念,你可以很方便使用注解,就能實現變量的的設置,在各自的作用域內優雅的使用該變量。
閱讀全文
posted @
2016-03-10 20:02 alexcai 閱讀(2966) |
評論 (1) |
編輯 收藏
摘要: jenkins,作為開源世界的持續集成工具(CI),表現其實不錯了。雖然不能與Atlassian的bamboo相比,別人是商業版本。
我使用的是它的WAR包版本,可以從jenkins 官網下載。個人建議在tomcat7.0.32版本以上運行。
閱讀全文
posted @
2016-03-08 18:20 alexcai 閱讀(2402) |
評論 (0) |
編輯 收藏
摘要: quartz,java世界里面的任務管理容器。
至于為什么會有misfire這個概念,我想可以重這三個方面來進行說明:
1 所有的線程都在忙于更高優先級的任務
2 任務本身CRASH了
3 代碼的BUG,導置錯誤的設置了JOB
閱讀全文
posted @
2016-03-03 15:58 alexcai 閱讀(4969) |
評論 (0) |
編輯 收藏
摘要: 為什么需要一致性hash算法?
在緩存應用層面,如何保證數據訪問的平橫性,單調性?
平橫性:主要是數據的平均分布,及當集群中某一個緩存服務失效,數據也能夠正常分布
單調性:當數據插入某個緩存之后,再次調用,同樣會落到對應的緩存上面。
閱讀全文
posted @
2016-03-02 18:36 alexcai 閱讀(3020) |
評論 (1) |
編輯 收藏
摘要: spring mvc作為展示層的組件,從參數預處理,驗證,攔截,渲染。無不考慮的細致入微,你所要的做的,只是接口實現,切面接入,簡單配置。
今天我們以分頁功能展開來說明,如何把我們復雜的參數處理從控制器進行剝離!
閱讀全文
posted @
2016-02-24 10:49 alexcai 閱讀(2925) |
評論 (1) |
編輯 收藏
摘要: 最近一直在看倪超的那本《從paxos到Zookeeper分布式一致性原理與實踐》,整本書干貨滿滿。個人感覺在章節順序編排上有些小問題,不過,不影響它作為介紹這款中間件產品特性及原理而全面闡述的開山之作。總之,內容很多,我也只是了解了皮毛。接下來寫的種種,算是我喝了這碗雞湯,消化來剩下的。
閱讀全文
posted @
2016-02-01 17:57 alexcai 閱讀(4897) |
評論 (0) |
編輯 收藏
摘要: mybatis目前一直作為我主要使用的ORM框架,當然,它的簡單,SQL可控,高效才是我選擇它的最終原因。前段時間學習了他的實體,ORM的XML文件自動生成,感覺也是比較簡單。
閱讀全文
posted @
2016-01-30 13:45 alexcai 閱讀(3328) |
評論 (0) |
編輯 收藏
摘要: VisualVm與eclipse集成
閱讀全文
posted @
2016-01-20 10:48 alexcai 閱讀(3690) |
評論 (0) |
編輯 收藏
Thymeleaf 是一個純JAVA實現的,能處理XML/XHTML/HTML5 等模板文件解析的工具。他能處理一切基于XML文檔格式的文件。特別是在WEB展現層面,可以很流暢的進行頁面數據的渲染與顯示。通過其DOM解析技術,把模板樣式讀入內存(當啟用緩存模式),當頁面需要展現時,讀取內存中的樣式,通過與后端數據的封裝填充,最終顯示給用戶。這樣在大量用戶訪問的時候,可以降低頁面渲染產生的IO,提高用戶體驗。另外,對于開發者,他的學習成本也不高。內置是基于ONGL語法來支持頁面的語法,比如在SPRING下面,我們是這樣寫的:<form:inputText name="userName" value="${user.name}" />
在Thymeleaf下面,就是這樣的:
<input type="text" name="userName" value="James Carrot" th:value="${user.name}" />
學習成本基本為零。他的牛B在于與HTML的靜態頁面一起存在時,毫無諱和感。這種叫作自然語言模板。很多所謂的模板語言,都是去定義一大堆小白用戶根本看不懂的標簽,語法,讓人望而生畏。而他只是HTML原生語義添加了屬性,就算用戶直接訪問,沒有后臺服務的啟動,也是完全不影響期頁面效果顯示的。
今天就到這里,明天來干貨。他是如何處理文本的?
posted @
2015-12-30 12:35 alexcai 閱讀(3564) |
評論 (4) |
編輯 收藏
摘要: beanshell是一個輕量級的腳本語言,具有動態性,完全支持JAVA語法。原理就是通過JAVA的反射獲得JAVA語句和表達式的實時執行能力。
閱讀全文
posted @
2015-12-18 10:15 alexcai 閱讀(3748) |
評論 (1) |
編輯 收藏
摘要: resin3到resin4變化確實挺大的。個人比較鐘情于tomcat,不知道公司那幫人為毛選擇resin,并且還不是收費版本的,這是要鬧哪樣!!!唉。今天,處理了一個項目上的性能問題,需要通過jmeter壓測一下,看看到底有沒有提升。當我部署到實體機上是,服務老是啟不來。
閱讀全文
posted @
2015-12-11 14:10 alexcai 閱讀(2355) |
評論 (0) |
編輯 收藏
摘要: 高CPU占用排查
閱讀全文
posted @
2015-12-10 17:58 alexcai 閱讀(2864) |
評論 (2) |
編輯 收藏
摘要: 對于后端的參數校驗,我們一直在強調的驗證規則,提示信息的重用。這不,springmvc通過集成Valid最大程序減少了我們的工作量。其實后端的參數過濾,是分幾種請求來源的。每種的處理都不太一樣,但是我們如果能重用驗證規則,提示信息,那就很強大了。
閱讀全文
posted @
2015-11-27 17:12 alexcai 閱讀(5592) |
評論 (3) |
編輯 收藏