java
摘要: objectid是一種輕量型的,不同的機器都能用全局唯一的同種方法輕量的生成它,而不是采用傳統的自增的主鍵策略,因為在多臺服務器上同步自動增加主鍵既費力又費時,不得不佩服,mongodb從開始設計就被定義為分布式數據庫。
下面深入一點來翻翻這個Objectid的底細,在mongodb集合中的每個document中都必須有一個"_id"建,這個鍵的值可以是任何類型的,在默認的情況下是個Objectid對象。
當我們讓一個collection中插入一條不帶_id的記錄,系統會自動地生成一個_id的key 閱讀全文
下面深入一點來翻翻這個Objectid的底細,在mongodb集合中的每個document中都必須有一個"_id"建,這個鍵的值可以是任何類型的,在默認的情況下是個Objectid對象。
當我們讓一個collection中插入一條不帶_id的記錄,系統會自動地生成一個_id的key 閱讀全文
摘要: 有朋友去一家大型的互聯網公司參加了java程序員的筆試,抄下了一些筆試題,可能有的抄的并不全,試了解答一下,有些還真的答不出來
1.cookie和session的作用以及他們的應用場合
2.怎樣讓jvm加載一個Class的同時執行一段代碼
3.post和get區別
4.事務的屬性有哪些?寫出spring或jdbc管理事務的例子
5.實現一個高并發、高性能的hashmap。寫出偽代碼
6.解析一段xml,拼接成一個url。 閱讀全文
1.cookie和session的作用以及他們的應用場合
2.怎樣讓jvm加載一個Class的同時執行一段代碼
3.post和get區別
4.事務的屬性有哪些?寫出spring或jdbc管理事務的例子
5.實現一個高并發、高性能的hashmap。寫出偽代碼
6.解析一段xml,拼接成一個url。 閱讀全文
摘要: 由于歷史原因,幾個項目都選用hessian作為web service的實現方式,hessian的確是非常輕量級,基于http協議進行傳輸,通過自定義的串行化機制將請求信息進行序列化,以二進制傳輸節省了不少的開銷,速度跟socket差不多.客戶端和服務器發起和接收請求都是通過spring提供的hessian api進行請求和接收,但是在服務端中并沒有記錄和控制遠端ip地址和主機的信息,所以需要對源碼進行一些重寫
對org.springframework.remoting.caucho.HessianServiceExporter進行重寫
/**
* 重寫HessianServiceExporter.handleRequest(),攔截獲取遠端調用信息
* @author chenyz
*
*/
public class HouseHessianServiceExporter extends HessianServiceExporter {
private static S 閱讀全文
對org.springframework.remoting.caucho.HessianServiceExporter進行重寫
/**
* 重寫HessianServiceExporter.handleRequest(),攔截獲取遠端調用信息
* @author chenyz
*
*/
public class HouseHessianServiceExporter extends HessianServiceExporter {
private static S 閱讀全文
摘要: 目前幾套系統中主要使用的hessian進行遠程調用webservice服務的有hessian的 HessianProxyFactory(com.caucho.hessian.client.HessianProxyFactory)和 spring的 HessianProxyFactoryBean(org.springframework.remoting.caucho.HessianProxyFactoryBean).
1.HessianProxyFactory
查看HessianProxyFactory源碼后發現,hessian在創建http請求連接webservice服務并沒有對連接超時進行相關的參數設置,所以當網絡出現問題就會造成整個hessian處理的阻塞,進而阻塞整個線程后續的處理
以下是HessianProxyFactory對連接處理的源碼
protected URLConnection openConnection(URL url)
throws IOException
{
URL 閱讀全文
1.HessianProxyFactory
查看HessianProxyFactory源碼后發現,hessian在創建http請求連接webservice服務并沒有對連接超時進行相關的參數設置,所以當網絡出現問題就會造成整個hessian處理的阻塞,進而阻塞整個線程后續的處理
以下是HessianProxyFactory對連接處理的源碼
protected URLConnection openConnection(URL url)
throws IOException
{
URL 閱讀全文
摘要: 下面一個伴隨了好幾個工程的時間操作的工具類,提供了一些常用的時間操作和計算的方法,每段時間都會進行一次整理,希望能去冗余和得到好的擴展
package com.***.product.util;
import java.text.ParsePosition;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;
import java.util.regex.Pattern;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class DateUtil {
protected static Log logger = LogFa 閱讀全文
package com.***.product.util;
import java.text.ParsePosition;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;
import java.util.regex.Pattern;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class DateUtil {
protected static Log logger = LogFa 閱讀全文
摘要: 大名鼎鼎的分布式緩存系統memcached,在開源社區中可謂是無人不知無人不曉,memcached支持分布式的橫向擴展,但memcached的服務端卻是單實例,并無"分布式"的功能,所謂的分布式只是客戶端在存儲的主鍵做分布的存儲;還有memcached組件緩存對象,如果組件無進行序列化必定無法正確取得數據;如何使用memcached的java組件來監控memcached的運行狀態;以上等等的問題是我在日常的工作中碰到并解決的,拿出來跟大家做個分享^_^
對象的序列化
首先memcached是獨立的服務器組件,獨立于應用系統,從客戶端保存和讀取對象到memcached是必須通過網絡傳輸,因為網絡傳輸都是二進制的數據,所以所有的對象都必須經過序列化,否則無法存儲到memcahced的服務器端.
正如我們以往在集群中應用的序列化一樣,memcached的序列化的性能也是往往讓大家頭疼,如果我們對我們的domain類進行對象的序列化,第一次序列化時間會比較長,但后續會優化,也就是說序列化最大的消耗不是對象的序列化,而是類的序列化,如果存儲的只是一個String 閱讀全文
對象的序列化
首先memcached是獨立的服務器組件,獨立于應用系統,從客戶端保存和讀取對象到memcached是必須通過網絡傳輸,因為網絡傳輸都是二進制的數據,所以所有的對象都必須經過序列化,否則無法存儲到memcahced的服務器端.
正如我們以往在集群中應用的序列化一樣,memcached的序列化的性能也是往往讓大家頭疼,如果我們對我們的domain類進行對象的序列化,第一次序列化時間會比較長,但后續會優化,也就是說序列化最大的消耗不是對象的序列化,而是類的序列化,如果存儲的只是一個String 閱讀全文
摘要: 上個月參加的網易游戲部QA組的黑盒測試培訓,覺得挺有意思的,不過最讓我感興趣的是,能和真正專業的測試人員做了一點討論,發現站在開發人員的角度看待測試和站在測試人員看待測試時完全不同的一種東西.
程序員和測試人員的心理差別
程序員和測試人員的心理差別可以簡單的歸納為以下幾種
成功 / 不成功
什么才是一次成功的測試,大多數的開發人員對自己的程序測試完沒發現錯誤,就會說"這是一個成功的測試",如果發現某些新的錯誤則稱"這是不成功的測試";而測試人員剛好相反,當然這也是因為雙方的職責不同而引起的
維護 / 破壞,施虐
開發人員對測試往往是一種維護性的測試,目標在于證明自己開發的程序沒有錯誤,可能跟我們開發人員經常做建設性工作,更傾向創造事物,而不是將事物破壞有關;而測試人員在測試更多是一種破壞的過程,甚至是一種施虐,擺出一種把雞蛋打碎攪黃來挑骨頭的姿態 閱讀全文
程序員和測試人員的心理差別
程序員和測試人員的心理差別可以簡單的歸納為以下幾種
成功 / 不成功
什么才是一次成功的測試,大多數的開發人員對自己的程序測試完沒發現錯誤,就會說"這是一個成功的測試",如果發現某些新的錯誤則稱"這是不成功的測試";而測試人員剛好相反,當然這也是因為雙方的職責不同而引起的
維護 / 破壞,施虐
開發人員對測試往往是一種維護性的測試,目標在于證明自己開發的程序沒有錯誤,可能跟我們開發人員經常做建設性工作,更傾向創造事物,而不是將事物破壞有關;而測試人員在測試更多是一種破壞的過程,甚至是一種施虐,擺出一種把雞蛋打碎攪黃來挑骨頭的姿態 閱讀全文
摘要: 把我上次的工程所用到的jar包做了一個整理,也加了一些簡單的描述,下面圖是上次工程用到的所有jar吧
JAR包與描述對照表 注:jar包尾后的版本號不代表當前最高版本
activation-1.1.jar Sun的JavaBeans Activation Framework(JAF),JavaMail要運行必須依賴于它的支持
asm-3.0.jar
asm-commons-2.2.3.jar
asm-util-2.2.3.jar
asm是一個輕量級字節碼處理和分析框架
alveole-struts2.jar
alveole-tools.jar
aspectjtools-1.5.3.jar
Aspect提供的注釋類庫和相應的解析類庫
atomikos-util.jar
數據庫提供分布式事務支持
閱讀全文
JAR包與描述對照表 注:jar包尾后的版本號不代表當前最高版本
activation-1.1.jar Sun的JavaBeans Activation Framework(JAF),JavaMail要運行必須依賴于它的支持
asm-3.0.jar
asm-commons-2.2.3.jar
asm-util-2.2.3.jar
asm是一個輕量級字節碼處理和分析框架
alveole-struts2.jar
alveole-tools.jar
aspectjtools-1.5.3.jar
Aspect提供的注釋類庫和相應的解析類庫
atomikos-util.jar
數據庫提供分布式事務支持
閱讀全文
摘要: 先感謝同事renial的<解析xml時遇到的一些問題>技術分享,下面是一些記錄和實際操作
1.使用Dom4j解析大文件時內存溢出的問題
問題是這樣的,當我用dom4j去解析一個幾十M的xml時,就出現out of memory.當然了,這也是根據你的機器性能而定的,我們都知道dom4j在各種DOM解析器中應該算是性能最好的,連大名鼎鼎的Hibernate都是用dom4j來解析XML配置文件的
問題出在于使用dom4j的SAXReader是會把整個XML文件一次性讀入,如果XML文件過大就會拋出out of memory,但即使是使用SAXParser批量讀入解析,但它也是一次解析完,假設XML文件有幾萬條數據,那么解析后就必須在內存放入這幾萬條對象.
常用的Dom4j文件解析方式:
InputStream is = new FileInputStream(filePath);
SAXReader reader = new SAXReader(); //將整個XML構建為一個Document
閱讀全文
1.使用Dom4j解析大文件時內存溢出的問題
問題是這樣的,當我用dom4j去解析一個幾十M的xml時,就出現out of memory.當然了,這也是根據你的機器性能而定的,我們都知道dom4j在各種DOM解析器中應該算是性能最好的,連大名鼎鼎的Hibernate都是用dom4j來解析XML配置文件的
問題出在于使用dom4j的SAXReader是會把整個XML文件一次性讀入,如果XML文件過大就會拋出out of memory,但即使是使用SAXParser批量讀入解析,但它也是一次解析完,假設XML文件有幾萬條數據,那么解析后就必須在內存放入這幾萬條對象.
常用的Dom4j文件解析方式:
InputStream is = new FileInputStream(filePath);
SAXReader reader = new SAXReader(); //將整個XML構建為一個Document
閱讀全文