原创 聲明式事務和自動代理初步認識 和 最近用到的重構

我所在的公司一直是使用這種方式 進行spring上的事務控制的 先放代碼: <bean id="transactionInterceptor" class="org.springframework.transaction.

原创 int自動封裝Integer的小知識(轉載)

Java是一個近乎純潔的面向對象編程語言,但是爲了編程的方便還是引入了基本數據類型,但是爲了能夠將這些基本數據類型當成對象操作,Java爲每一個基本數據類型都引入了對應的包裝類型(wrapper class),int的包裝類就是I

原创 字符串操作技巧

1、遞歸實現字符串倒序 public static String reverse(String originStr) { if(originStr == null || originStr.length() <= 1)

原创 別把重構和設計當做書上的東西~~!

再寫一些吧,之前一段時間發現我過分的想要使用重構的技術,保證自己的代碼是優雅的、易於維護的,但有時候是不適合重構的。 之前看<重構>的時候,覺得有好多地方都可以重構,但後來發現每當自己重構的時候,就會給自己惹來一大堆麻煩,就好像《ef

原创 private屬性是否可以被繼承

在我看來, 子類繼承父類的一切東西. <Thinking in JAVA>中說到, 子類對象擁有父類對象的完整拷貝. 實例化一個類是從最頂級的超類開始實例化的, 是一層一層的包裹結構. private限制訪問方式只能在類的內部, 這僅僅是

原创 重寫hashcode的原因 以及爲啥用31的個人理解

首先聲明自己大部分的理解的出處:如何重寫hashCode()和equals()方法 接下來自己的理解: 1、首先java中set 、HashMap貌似包括List等底層的存儲都會把,存儲區域分成n個部分,而具體存在哪個

原创 線程池執行任務後,返回值接收(轉載)

原文地址 http://blog.csdn.net/qq_25806863/article/details/71214033 一般使用線程池執行任務都是調用的execute方法,這個方法定義在Executor接口中: public in

原创 (轉載)JVM對類的加載順序 (之前盡然有個點記錯了兩年~~)

摘要:  我們知道,一個.java文件在編譯後會形成相應的一個或多個Class文件,這些Class文件中描述了類的各種信息,並且它們最終都需要被加載到虛擬機中才能被運行和使用。事實上,虛擬機把描述類的數據從Class文件加載到內存,並對數

原创 jedis 各類方法示例

package com.wujintao.redis; import java.util.Date; import java.util.HashMap; import java.util.Iterator; impo

原创 (轉發)賊牛逼的雙數據源切換 贊一個 PS:關於最後事物無法切換的問題 也有解決方案 後續補上

AbstractRoutingDataSource動態數據源切換上週末,室友通宵達旦的敲代碼處理他的多數據源的問題,搞的非常的緊張,也和我聊了聊天,大概的瞭解了他的業務的需求。一般的情況下我們都是使用SSH或者SSM框架進行處理我們的數據

原创 (轉載)Java類加載機制(講道理分析的賊牛逼)

Java類加載機制   類加載器          虛擬機設計團隊把類加載階段中的“通過一個類的全限定名來獲取描述此類的二進制字節流”這個動作放到Java虛擬機外部去實現,以便讓應用程序自己決定如何去獲取所需要的類。實現這個動作的代碼模塊

原创 (轉)分佈式全局唯一ID生成策略

分佈式全局唯一ID生成策略   爲什麼分佈式系統需要用到ID生成系統 在複雜分佈式系統中,往往需要對大量的數據和消息進行唯一標識。如在美團點評的金融、支付、餐飲、酒店、貓眼電影等產品的系統中,數據日漸增長,對數據庫的分庫分表後需要有一個唯

原创 (轉載)ThreadLocal的實現原理,SpringMvc的單例線程安全就是用這個實現的

1. 背景 ThreadLocal源碼解讀,網上面早已經氾濫了,大多比較淺,甚至有的連基本原理都說的很有問題,包括百度搜索出來的第一篇高訪問量博文,說ThreadLocal內部有個map,鍵爲線程對象,太誤導人了。 ThreadLo

原创 面向對象的六原則 一法則簡述

單一職責原則:一個類只做它該做的事情。(單一職責原則想表達的就是”高內聚”,寫代碼最終極的原則只有六個字”高內聚、低耦合”,就如同葵花寶典或辟邪劍譜的中心思想就八個字”欲練此功必先自宮”,所謂的高內聚就是一個代碼模塊只完成一項功能,在面

原创 關於ETCD和Zookeeper的一些簡單瞭解(轉)

如果使用預定義的端口,服務越多,發生衝突的可能性越大,畢竟,不可能有兩個服務監聽同一個端口。管理一個擁擠的比方說被幾百個服務所使用的所有端口的列表,本身就是一個挑戰,添加到該列表後,這些服務需要的數據庫和數量會日益增多。因此我們應該部署無