JDK源码感悟

首先有一个很有趣的问题，在JDK源码里，如果if或者while里只有一行，是习惯进行缩进而省略{}的，有一种很明显的感觉就是，JDK的源码除了泛型这一不同，其他部分处处体现这严蔚敏的数据结构处理数据的思想,也就是说JDK在封装方法时，只有数据的类型不能确定，因为面向对象的时候，往往传的数据类型就是对象类型的，而对象的类型又是千变万化的，这样就需要有一种泛指对象的数据类型的声明，也就是泛型，可以说泛型是面向对象封装方法的基石，如果一定要说对象是某种类型的话，那么这种类型一定是泛化而绝非特指，就像int与1的关系，int是泛化，1是泛化的特指此外，源码中对于传进来的参数往往进行验证合理合法性后才会进行操作，一旦验证到参数有问题，就会主动抛出异常.
多方法使用了native修饰使用native关键字说明这个方法是原生函数，也就是这个方法是用C/C++语言实现的，并且被编译成了DLL，由java去调用。这些函数的实现体在DLL中，JDK的源代码中并不包含，你应该是看不到的。对于不同的平台它们也是不同的。这也是java的底层机制，实际上java就是在不同的平台上调用不同的native方法实现对操作系统的访问的。很多变量使用transient修饰，这个单词的意思是暂时的，短暂的.
像set，list能够装进各种类型数据的容器，源码里惯用Object[] ,所谓的栈，队列，线性表不过是对普通数组的使用方式进行了限制而已，比如说参数里出现 Collection<? extends E> c 的意思是对于接受c这样一个对象，c对应的类不应该超过E的类型，c是E的子类，E是泛型，是待确定的，，而 Collection<? super E> c 的意思是对于接受c这样一个对象，c是E的父类，c也可以是E类型的，E是泛型，这两者用来限制元素的类型的上限和下限，Java的序列化机制是通过判断类的serialVersionUID来验证版本一致性的。serialVersionUID是long类型，且不可更改的，在进行反序列化时，JVM会把传来的字节流中serialVersionUID与本地相应实体类的serialVersionUID进行比较，如果相同就认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常.
不得不提一下红黑树，查阅的资料说红黑树是相对的接近的平衡二叉树，讲真平衡二叉树的特点：中序遍历有序，以及高效的查找效率，最最有趣的是节点插入时平衡被破坏后的进行左旋右旋和红黑树一模一样。String类的hashcode实现

public int hashCode() {       
 int h = hash;//hash的默认值是0     
    if (h == 0 && value.length > 0) {      
          char val[] = value;//value就是字符串     
          for (int i = 0; i < value.length; i++) {     
                   h = 31 * h + val[i];//字符串的字符val[i]与h*31和进行迭代运算         
           }           
           hash = h;     
     }        
   return h;

对于引用型数据，实际值就是地址，两个引用型的数据可能引用的是同一个对象，但是这两个引用型数据进行hashcode运算，由于value不同即地址不同，很大几率（hash碰撞）hashcode不一样，因此hashcode的生产方式，hashcode本就应该根据对象的特点去生产不同的hashcode，也就是说hashcode应当依据实际应用随时改变，这也是无可厚非的。