（一）問題

         項目中需要對文件做md5sum，分兩步走：1、對文件流的每個字節用md5實例進行update，然后進行digest。2、digest返回長度為16的byte數組，一般我們需要把byte數組轉成16進制字符串（很多開源的md5加密算法如此實現，真正的原因還不是很理解，可能是便于查看和傳輸）。具體的實現代碼如下：

         /**

    * 對文件進行md5 sum操作

    * @param checkFile 要進行做md5 sum的文件

    * @return

    */

    public static String md5sum(File checkFile){

       String md5sumResult = "";

       if(checkFile == null || (!checkFile.exists())){

           return md5sumResult;

       }

       MessageDigest digest = MessageDigest.getInstance("MD5");

       InputStream is = new FileInputStream(checkFile);

       byte[] buffer = new byte[8192];

       int read = 0;

       try {

           while( (read = is.read(buffer)) > 0) {

              digest.update(buffer, 0, read);

           }

           byte[] md5sum = digest.digest();

           BigInteger bigInt = new BigInteger(1, md5sum);

           md5sumResult = bigInt.toString(16);

       }

       catch(IOException e) {

           throw new RuntimeException("Unable to process file for MD5", e);

       }

       finally {

           try {

              is.close();

           }

           catch(IOException e) {

              throw new RuntimeException("Unable to close input stream for MD5 calculation", e);

           }

       }

       return md5sumResult;

    }

    其中黃色背景色的轉換方式是有問題的。為什么用bigint轉16進制會有問題呢，原因是bigint進行16進制轉換的時候第一個0被自動去掉了.

（二）正確解決方式

那正確的方式是怎么樣的呢？下面有兩種不同的轉換方式，但是原理其實是一致的。

    第一種正確的方式（由王建提供）：

    /**

    * 將字節數組轉換為16進制字符串

    *

    * @param buffer

    * @return

    */

   public static String toHex(byte[] buffer) {

      StringBuffer sb = new StringBuffer(buffer.length * 2);

      for (int i = 0; i < buffer.length; i++) {

       sb.append(Character.forDigit((buffer[i] & 240) >> 4, 16));

       sb.append(Character.forDigit(buffer[i] & 15, 16));

      }

      return sb.toString();

   }

    第二種正確的方式：

    public static String bytes2HexString(byte[] b) {

       String ret = "";

       for (int i = 0; i < b.length; i++) {

           String hex = Integer.toHexString(b[i] & 0xFF);

           if (hex.length() == 1) {

              hex = '0' + hex;

           }

           ret += hex;

       }

       return ret;

    }

（三）問題分析

    Md5算法對任何長度的字符串進行編碼最后輸出是128位長整數，也就是長度為16的byte數組。我們項目調用的是jdk實現的md5算法，所以一般是沒問題的。

    接下來我們要處理的事情，分別循環數組，把每個字節轉換成2個16進制字符，也就是說每4位轉成一個16進制字符。

    上面正確的兩種方式也就是做了這樣的事情。

    第一種方式：

       Character.forDigit((buffer[i] & 240) >> 4, 16)把字節的高4位取出右移4位換算成int，然后通過forDigit轉換成16進制字符

       Character.forDigit(buffer[i] & 15, 16)把字節的低4位取出換算成int，然后通過forDigit轉換成16進制字符

    第二種方式：

       Integer.toHexString(b[i] & 0xFF)把整個字節轉成int，然后toHexString也就是做高4位和低4位的運算。但是這個方法如果高四位是0的話就不輸出任何東西，

所以在輸出的字符前加0即可。

       b[i] & 0xFF就是把byte轉成int，為什么用與oxff做與運算，是因為如果b[i]是負數的話，從8位變成32位會補1，所以需要與0xff做與運算，可以把前面的24位全部清零，又可以表示成原來的字節了。

附：

盡量使用開源提供的工具包，比如：

org.apache.commons.codec.digest.DigestUtils.md5Hex(InputStream data)來對文件流進行md5即可，更加方便，可靠。

早期的java程序員可能只要懂基本語法，還有少數的項目經驗就可以找到一份比較好的工作。Java和java社區的發展，更多的人了解它，深入它。現在java程序員了解一些語法我看還遠遠不夠了，對于jvm的了解和深入是非常重要的。網民的增多，網站的剛性需求，很多網站面臨高性能，高并發等等一系列的問題。沒有深入jvm的java程序員是很難寫出高質量高并發的代碼（也許一棒子打死所有人了，但我想絕大部分是肯定的）。

Osgi也許你并不陌生，但是他底層的實現機制你可能沒去了解過。如果你是個打破砂鍋問到底的人，你肯定會想知道osgi是如何做到的。但是你沒有了解jvm的類加載體系，你肯定很難理解osgi是如果做到類隔離等一系列的問題。不過想完整理解osgi還需要其他很多方面的知識，但是它基本的機制還是的了解jvm的類加載機制。

Java類庫有些包只是定義了一個標準，具體的實現都是由具體的供應商來提供。Java與數據庫連接就是一個很好的例子。Java.sql類庫只是定義了java與數據庫連接的標準，那么與mysql就需要msyql的驅動，oracle就需要oracle的驅動，而java.sql類庫是由bootstrap classloader加載，驅動包中的類是由system classloader來加載，不同類加載器加載的類是無法相互認識，所以自然也無法正常提供功能了。jvm又是提供了什么機制讓他們交互呢？如果你確實對這些問題毫無頭緒的話，那么我覺得你真的要好好理解下jvm類加載體系。

這篇文章主要是介紹下jvm類加載的機制基礎知識。關于其他相關涉及，有時間的話，我會單獨寫文章來介紹。

1、 java類加載器

1.1 Bootstrap classloader：sun jdk是用c++實現，所以在代碼中你是無法獲取此加載器的實例。此加載器主要負責加載$JAVA_HOME/jre/lib/rt.jar。java類中獲取結果為null，這里可以用一個例子跑下證明：

public class Test {

         public static void main(String[] arg) throws Exception{

                   ClassLoader classloader = Test.class.getClassLoader();

                   System.out.println(classloader);

                   System.out.println(classloader.getParent());

                   System.out.println(classloader.getParent().getParent());

         }

}

輸出結果：

sun.misc.Launcher$AppClassLoader@19821f

sun.misc.Launcher$ExtClassLoader@addbf1

null

最后輸出的null就是代表bootstrap classloader。

1.2 Extension classloader：主要加載擴展功能的jar，$JAVA_HOME/jre/lib/ext/*.jar。

1.3 System classloader：加載claspath中的jar包。

1.4自定義 classloader：主要加載你指定的目錄中的包和類。

2、 雙親委派模型

系統運行時，我們請求加載String類，此時System Classloader自己不找classpath中的包，把請求轉發給Extension Classloader，但它也不做查找，又轉發給Bootstrap Classloader，但是它發現自己沒有parent了。于是他在rt.jar包中找到String類并加載到jvm中提供使用。Jvm為什么要這么實現呢？其實和java安全體系有關。假設jvm不是這么實現，我們自定義一個String類，做一些破壞，那么運行jvm的機器肯定要受到損壞。具體例子：

public class String {

         public static void main(String[] args) {

                   System.out.println("hello world");

         }

}

我們運行自定義String類的時候報錯了，說沒有main方法，可我們定義的明明有的，嘿嘿，委派機制的緣故最后加載到的是由bootstrap classloader在rt.jar包中的String，那個類是沒有main方法，因此報錯了。

3、 類隔離

jvm中的類是：類加載器+包名+類名。比如：URLClassLoader1，URLClassLoader2分別加載com.test.Test的時候會加載兩次，因為每個classloader中的類對于其他classloader來說是隔離的，不認識的。例子：

import java.net.URL;
import java.net.URLClassLoader;

public class CustomClassloaderTest {
    public static void main(String[] args) throws Exception {
        URL url = new URL("file:/g:/");
        URLClassLoader ucl = new URLClassLoader(new URL[]{url});
        Class c = ucl.loadClass("Yang");
        c.newInstance();
        System.out.println(c.getClassLoader());

        URLClassLoader ucl2 = new URLClassLoader(new URL[]{url});
        Class c2 = ucl2.loadClass("Yang");
        c2.newInstance();
        System.out.println(c2.getClassLoader());
    }
}

大家把Yang類存在g盤下。

public class Yang {
    static {
        System.out.println("Yang");
    }
}

運行結果：

Yang

java.net.URLClassLoader@c17164

Yang

java.net.URLClassLoader@61de33

看到每次加載Yang類的時候都輸出Yang，說明Yang類被加載了兩次。

如果你不確信，可以修改下代碼，讓同一classloader加載Yang類兩次

import java.net.URL;
import java.net.URLClassLoader;

public class CustomClassloaderTest {
    public static void main(String[] args) throws Exception {
        URL url = new URL("file:/g:/");
        URLClassLoader ucl = new URLClassLoader(new URL[]{url});
        Class c = ucl.loadClass("Yang");
        c.newInstance();
        System.out.println(c.getClassLoader());

        Class c2 = ucl.loadClass("Yang");
        c2.newInstance();
        System.out.println(c2.getClassLoader());
    }
}

看看輸出結果：

Yang

java.net.URLClassLoader@c17164

java.net.URLClassLoader@c17164

結果中只輸出了一次Yang。因此可以證明我們最開始說的類隔離。

4、 線程上下文類加載器

我們理解了雙親委派模型，那么目前只有由下向上單向尋找類（system->extension->bootstrap）

。我們在最開始的時候說過，java.sql包中的類由bootstrap或extension classloader加載，而mysql驅動包是在classpath中由system來加載，但bootstrap中的類是無法找到system classloader中的類，此時靠線程上下文類加載器來解決。線程上下文類加載器主要就是能讓jvm類加載模型具有了向下尋找的可能，bootstrap->extension->system，如果不做任何設置，線程上下文類加載器默認是system classloader。本來這里想寫一個例子的，可是有點麻煩，所以下次單獨寫一篇關于這方面的知識。