一堆踩過的坑,吐血

1、Spring Data Redis 1.1.1

1. 簡而言之別用這個庫. Jedis就夠用.
2. ListOperations<String, String> ＝ StringRedisTemplate 存數據時沒問題，但若是用RedisTemplate<String, String>時，保存的key是亂碼。直接用那個DefaultRedisConnection。不過整個Spring Data Redis其實沒什麼意義，不如直接用Jedis，但Jedis的鏈接池有問題，若是出錯時return資源要用returnBrokenResource而不是returnResource，不然用同一個Jedis再次發指令時會出錯。
3. 當使用jedis引擎時必須依賴jedis包，但Reference裏沒寫。
4. Spring Data Redis 1.1.1依賴的是jedis 2.1.0，且須要使用commons-pool 1.6（jedis 2.4.1不兼容，由於換用commons-pool 2.2）

 

2、Spring Framework 4.0.2

1. 在多個Config裏（包括Annotation和XML）指定多個properties文件定義時，加載是按最後一個定義的文件來讀，前邊的文件會被忽略，致使使用${"abc"}來讀屬性時會出錯。
2. context:component-scan遍歷邏輯是先下層目錄(子優先遍歷)，再到根目錄來讀.根目錄下若是有@Configation定義,對應的properties文件會被讀取，但初始化時又先按子目錄優先來初始化。致使下層目錄的@Configation定義的properties文件讀不出.最終初始化可能會失敗.
3. 設置了task:scheduler但沒task:executor時，若是任務線程執行較慢或掛起，fixdelay的任務會無限建立新線程。建議設置task:executor 的 rejection-policy="CALLER_RUNS"

 

3、ActiveMQ 5.9.0

1. 此版本未解決發送超時，當鏈接成功以後，發送前若是把ActiveMQ進程kill掉，整個Client線程就掛起很長一段時間。
2. ActiveMQ的協議文檔裏，一些參數都要加上"transport."爲前綴，實際上程序根本不認，須要去掉這個前綴纔不會報錯。
3. 一堆超時設置沒發現什麼用，包括soWriteTimeout,soTimeout,connectionTimeout=1000。若是直接把ActiveMQ直接退出以後，線程就一直掛起。實際生產時若是網線有問題或機架掉電,程序會掛起1小時以上沒反應.
4. 簡單的輪循消息隊列建議用Redis實現，真心吞吐量大N倍。若是怕隊列由於掉電丟失，能夠多用save或bgsave指令要求當即保存數據，不過會下降性能。

 

4、HTMLUnit 2.14

1. 神奇且強大的東東,基本就是無界面的瀏覽器,如今對特殊javascript庫(好比修改過的jquery之類)的支持還有問題,其它已經比較完善了.
2. QQ空間上JS寫入的iFrame不能用任何方法正確拿到Frame並訪問其屬性。使用 BrowserVersion.FIREFOX_24 能夠拿IFrame,但沒有src和id屬性,估計是JS未正確執行.請有研究的同窗分享一下解決方案.
3. JS執行是新開Runnable線程，因此用JMX監控時會一直增長，影響對其它問題的判斷。沒有解決方案. 現時使用 common-pool2 來控制 ,可有效減小線程持續增長.

 

5、Redis Win64 2.6.12

1. redis-cli不支持utf-8的數據,好像Linux版也不支持
2. 和VMWare彷佛有衝突,VMWare打開以後鏈接就出錯。
3. 這個windows版稍長時間運行不太穩定,響應好像會變慢,暫未肯定緣由.
4. 按新浪的經驗,因爲redis是單線程,但因爲hget較慢,致使調用hget時其它請求掛起時間較長,可能會致使問題.新浪的方案是hget都由memcache檔一層.

 

6、Redis Desktop 0.7.5

1. 不能使用script功能
2. select N 以後不會當即改變提示符,但不影響操做.

 

6、ADT 22.6

1. 在eclipse內不能新建AVD。解決方法是在android-sdks\tools目錄下運行android.bat avd，出現AVD管理界面後再建立，所建立的AVD須要重啓Eclipse才能看見。新版已解決此問題.

 

7、Gradle

　　1.  版本號自動拿最新的方式是隻寫"+",而不是如今網上一大堆0.9.+這種寫法,那樣只匹配 0.9.1~0.9.X.一樣的寫法可應用於dependencies,不過考慮到穩定性,建議dependencies使用精確的版本號.

buildscript {
    repositories {
        maven { url 'http://dl.bintray.com/populov/maven' }
           mavenCentral()
        mavenLocal()
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:+' //注意這裏沒寫版本號
    }
}

　　2.  同時使用apply plugin: 'android' 和 apply plugin: 'eclipse' 的話,執行gradle eclipse並不能正常生成項目目錄結構,由於0.9.X的android插件未優化,不能正確生成.classpath和.project文件.而是按照默認的apply plugin: 'java' 來生成的.

　　3.  超多人在新手介紹文章都沒提到的內容,我廢了超多時間查資資料,哭啊 : 須要在文件根下增長repositories才能正確拿到jar或aar庫!buildscript裏的repositories不起做用的! F U C K!

repositories {
    maven { url 'http://dl.bintray.com/populov/maven' }
    mavenLocal()
    mavenCentral()
}

dependencies {
       compile 'com.android.support:appcompat-v7:19.1.+'
       compile 'com.android.support:support-v4:19.1.+'
       compile 'com.squareup.wire:wire-runtime:1.3.3'
       compile 'com.tonicartos:stickygridheaders:1.0.1'
       compile 'com.viewpagerindicator:library:2.4.1@aar'
       compile 'com.alibaba:fastjson:1.1.34.android'
       compile 'org.apache.httpcomponents:httpclient-android:4.3.3'
       
    //compile fileTree(dir: 'libs', include: '*.jar')
}

 

8、Gradle Eclipse 集成(Eclipse Kepler 4.3+STS 3.5)

1. Dependency management 無效,致使Gradle Dependencies 在package explorer不顯示, 且build.gradle增長的dependencies在classpath找不到. 只能手動把jar放到libs目錄或使用lib project.
2. 如今我調試時使用lib目錄下的包,編譯速度比較快. 但正式測試時使用gradle來build並install到測試機器.

 

9、Maven Android Eclipse 集成(Eclipse Kepler 4.3 + STS 3.5 + Android m2e 1.0 + maven-android-sdk-deployer)

1. 不建議使用,比gradle須要多寫一大堆,並且整合後的環境還有較多問題 . 不知道將來是否會優化到java環境同一個水平.
2. 優勢:
   1. 相對gradle支持Dependency management 對classpath的修改,使得Eclipse開發時能夠不須要維護libs目錄下的庫.
   2. 插件比較豐富,好比wire和protostuff都有maven的代碼生成插件,從工程角度比gradle的自動化程度要好一點點.但做用不大.
   3. 因爲歷史悠久,網上資料多一些.
3. 缺點:
   1. 常見gradle優於maven的地方: XML配置文件不便於閱讀, 代碼行數多.google官方支持gradle構建.
   2. eclipse 集成還須要加dependencyManagement才能夠不報錯,雖然能夠自動生成,但增長了一大段內容,不利維護.主要是Android m2e 1.0不夠成熟.
   3. maven-android-sdk-deployer並不完善,使用默認的install通常不能正常跑完,須要進入到子目錄分步install.並且複製了不少SDK的文件,佔用硬件空間.且此deployer的庫命名規則隨版本演進有變化,不利於長期使用.

 

10、Resin 4.0.X

1. UTF-8問題，Windows下任何修改配置的方式都沒效，在不修改系統默認編碼時，解決方案以下：
   1. 普通HTML的UTF-8問題,能夠解決: 另存爲UTF-8帶BOM的格式(無BOM就會亂碼), 並以<?xml version="1.0" encoding="UTF-8" ?>開頭
   2. Java程序的UTF-8問題：須要修改起動器。分二種狀況：
      1. Eclipse Debug環境，須要修改eclipse.ini，在結尾增長 -Dfile.encoding=UTF-8
      2. 普通Windows運行環境，須要在運行時加參數：resin -Dfile.encoding=UTF-8 start

 

 11、Jersey 

1. 返回byte[],String之類不帶Content-Length,須要返回自定義Response才能解決.代碼見下.
2. UTF-8問題,代碼見下.

    @GET
    @Path("book")
    public Response getBook( @QueryParam("uri") String bookURI ){
        byte[] result= dao.loadBook(bookURI);
        
        if (result == null)
            throw new NotFoundException(bookURI);
        return Response.ok(result, "application/x-protobuf;charset=UTF-8")
                       .header("Content-Length",result.length)
                       .build();
    }