java基础

Java关键字new和newInstance的区别方法

String className = readfromXMlConfig;//从xml 配置文件中获得字符串 
class c = Class.forName(className); 
factory = (ExampleInterface)c.newInstance(); 
从JVM的角度看，我们使用关键字new创建一个类的时候，这个类可以没有被加载。但是使用newInstance()方法的时候，就必须保证：1、这个类已经加载；2、这个类已经连接了。而完成上面两个步骤的正是Class的静态方法forName()所完成的，这个静态方法调用了启动类加载器，即加载java API的那个加载器。 

 

关于Java栈与堆的思考

1、基本类型(primitive types), 共有8种，即int, short, long, byte, float, double, boolean, char(注意，并没有string的基本类型)。存在栈中，栈有一个很重要的特殊性，就是存在栈中的数据可以共享。假设我们同时定义
　　int a = 3; 
　　int b = 3；

a与b同时均指向3的情况。

2、包装类数据，如Integer, String, Double等将相应的基本数据类型包装起来的类。这些类数据全部存在于堆中，

3、String是一个特殊的包装类数据。即可以用String str = new String("abc");的形式来创建，也可以用String str = "abc"；的形式来创建。使用String str = "abc"；的方式，可以在一定程度上提高程序的运行速度，因为JVM会自动根据栈中数据的实际情况来决定是否有必要创建新对象。而对于String str = new String("abc")；的代码，则一概在堆中创建新对象。
　　String str1 = "abc";
　　String str2 = "abc";
　　System.out.println(str1==str2);  //true
我们再接着看以下的代码。
　　String str1 = "abc";
　　String str2 = new String("abc");
　　System.out.println(str1==str2);  //false
当比较包装类里面的数值是否相等时，用equals()方法；当测试两个包装类的引用是否指向同一个对象时，用==。

 

关于寻找class文件原理

建议大家在入门的时候在命令行窗口编译和运行，不要借助JCreator或者Eclipse等IDE去帮助做那些事情。尝试自己这样做：

javac     -classpath   yourpath   *.java

java     -classpath   yourpath   *.class

也许很多人都能看懂，设置classpath的目的就是告诉编译器去哪里寻找你的class文件.   不过至少笔者今日才弄懂JVM去查询类的原理，编译器加载类要依靠classloader，   而classloader有3个级别，从高到低分别是BootClassLoader(名字可能不准确)   ExtClassLoader,   AppClassLoader. 这3个加载器分别对应着编译器去寻找类文件的优先级别和不同的路径：BootClassLoader对应jre/classes路径，是编译器最优先寻找class的地方 ExtClassLoader对应jre/lib/ext路径，是编译器次优先寻找class的地方 AppClassLoader对应当前路径，所以也是编译器默认找class的地方。

 

关于jdk和jre

大家肯定在安装JDK的时候会有选择是否安装单独的jre，一般都会一起安装，我也建议大家这样做。因为这样更能帮助大家弄清楚它们的区别：

Jre   是java   runtime   environment, 是java程序的运行环境。既然是运行，当然要包含jvm，（jre/bin/client/jvm.dll），还有所有java类库的class文件，都在lib目录下打包成了jar。

Jdk   是java   development   kit，是java的开发工具包，里面包含了各种类库和工具。当然也包括了另外一个Jre。那么为什么要包括另外一个Jre呢？而且jdk/jre/bin同时有client和server两个文件夹下都包含一个jvm.dll。具备开发功能的jdk自己的jre下才会同时有client性质的jvm和server性质的 jvm，而仅仅作为运行环境的jre下只需要client性质的jvm.dll就够了。

环境变量path中设置jdk/bin路径，用的java命令并不是 jdk/bin目录下的而是jre/bin目录下的。安装jre的时候安装程序自动帮你把jre的java.exe添加到了系统变量中，验证的方法很简单，大家看到了系统环境变量的 path最前面有“%SystemRoot%\system32;%SystemRoot%;”这样的配置，那么再去Windows/system32下面去看看，有一个java.exe。如果强行能够把jdk/bin挪到system32变量前面，当然也可以迫使使用jdk/jre里面的java，不过除非有必要，我不建议大家这么做。使用单独的jre跑java程序也算是客户环境下的一种测试。

 

关于Object类理解

大家都知道Object是所有Java类的基类，   意味着所有的Java类都会继承了Object的11个方法。建议大家去看看Object的11个成员函数的源代码，就会知道默认的实现方式。比如equals方法，默认实现就是用"=="来比较，即直接比较内存地址，返回true或者false。而toString()方法，返回的串组成方式是??

        "getClass().getName()   +   "@"   +   Integer.toHexString(hashCode())"

其实不用我过多的解释，大家都能看懂这个串的组成。接下来再看看hashCode()：

        public   native   int   hashCode()；

由于是native方法，跟OS的处理方式相关，源代码里仅仅有一个声明罢了。我们有兴趣的话完全可以去深究它的hashCode到底是由OS怎么样产生的呢？但笔者建议最重要的还是先记住使用它的几条原则吧！首先如果equals()方法相同的对象具有相通的hashCode，但equals()对象不相通的时候并不保证hashCode()方法返回不同的整数。而且下一次运行同一个程序，同一个对象未必还是当初的那个hashCode()哦。其余的方法呢？nofigy()、notifyAll()、clone()、wait()都是native方法的，说明依赖于操作系统的实现。最后一个有趣的方法是finalize()，类似C++的析构函数，签名是protected，证明只有继承扩展了才能使用，方法体是空的，默示什么也不做。它的作用据笔者的了解仅仅是通知JVM此对象不再使用，随时可以被销毁，而实际的销毁权还是在于虚拟机手上。那么它真的什么也不做麽？未必，实际上如果是线程对象它会导致在一定范围内该线程的优先级别提高，导致更快的被销毁来节约内存提高性能。其实从常理来说，我们也可以大概这样猜测出jvm做法的目的。

 

关于重载hashCode()与Collection框架的关系

hashCode()方法到底做什么用？ 学过数据结构的课程大家都会知道有一种结构叫hash   table，目的是通过给每个对象分配一个唯一的索引来提高查询的效率。那么Java也不会肆意扭曲改变这个概念，所以hashCode唯一的作用就是为支持数据结构中的哈希表结构而存在的，换句话说，也就是只有用到集合框架的Hashtable、HashMap、HashSet的时候，才需要重载hashCode()方法，这样才能使得我们能人为的去控制在哈希结构中索引是否相等。笔者举一个例子：曾经为了写一个求解类程序，需要随机列出1,2,3,4组成的不同排列组合，所以笔者写了一个数组类用int[]来存组合结果，然后把随机产生的组合加入一个HashSet中，就是想利用HashSet不包括重复元素的特点。可是HashSet怎么判断是不是重复的元素呢？

当然是通过hashCode()返回的结果是否相等来判断啦，可做一下这个实验：

        int[]   A   =   {1,2,3,4};

        int[]   B   =   {1,2,3,4};

        System.out.println(A.hashCode());

        System.out.println(B.hashCode());

这明明是同一种组合，却是不同的hashCode，加入Set的时候会被当成不同的对象。这个时候我们就需要自己来重写hashCode()方法了，如何写呢？其实也是基于原始的hashCode()，毕竟那是操作系统的实现，找到相通对象唯一的标识，实现方式很多，笔者的实现方式是：

        首先重写了toString()方法:

        return     A[0]+ A[1]+ A[2]+ A[3];   //显示上比较直观

        然后利用toString()来计算hashCode()：

        return     this.toString().hashCode()；

这样上述A和B返回的就都是”1234”，在测试toString().hashCode()，由于String在内存中的副本是一样的，”1234”.hashCode()返回的一定是相同的结果。

 

关于Class类的成员函数与Java反射机制

在Java中，主要是通过java.lang包中的Class类和Method类来实现内存反射机制的。

再明显简单不过的例子就是自己写一个JavaBean的解析器：

        a.   通过Class.forName(“Bean的类名”)得到Class对象，例如叫ABeanClass

        b.   通过ABeanClass的getMethods()方法，得到Method[]对象

        c.   按照规范所有get方法名后的单词就代表着该Bean的一个属性

        d.   当已经知道一个方法名，可以调用newInstance()得到一个实例，然后通过invoke()方法将方法的名字和方法需要用的参数传递进去，就可以动态调用此方法。

当然还有更复杂的应用，这里就不赘述，大家可以参考Class类和Method类的方法。

 

坦言Synchronize的本质

Synchronize大家都知道是同步、加锁的意思，其实它的本质远没有大家想得那么复杂。声明Synchronize的方法被调用的时候，锁其实是加载对象上，当然如果是静态类则是加在类上的锁，调用结束锁被解除。它的实现原理很简单，仅仅是不让第二把锁再次被加在同一个对象或类上，仅此而已。一个简单的例子足以说明问题：

class   A{

synchronized   void   f(){}

void   g(){}

}

当A的一个对象a被第一个线程调用其f()方法的时候，第二个线程不能调用a的synchronized方法例如f()，因为那是在试图在对象上加第二把锁。但调用g()却是可以的，因为并没有在同一对象上加两把锁的行为产生。这样大家能理解了麽？明白它的原理能更好的帮助大家设计同步机制，不要滥用加锁。

 

关于序列化和反序列化

应该大家都大概知道Java中序列化和反序列化的意思，序列化就是把一个Java对象转换成二进制进行磁盘上传输或者网络流的传输，反序列化的意思就是把这个接受到的二进制流重新组装成原来的对象逆过程。它们在Java中分别是通过ObjectInputStream和   ObjectInputStream这两个类来实现的（以下分别用ois和oos来简称）。

oos的writeObject()方法用来执行序列化的过程，ois的readObject()用来执行反序列化的过程，在传输二进制流之前，需要讲这两个高层流对象连接到同一个Channel上，这个Channel可以是磁盘文件，也可以是socket底层流。所以无论用哪种方式，底层流对象都是以构造函数参数的形式传递进oos和ois这两个高层流，连接完毕了才可以进行二进制数据传输的。

 

例子：

        可以是文件流通道

        file   =   new   File(“C:/data.dat”);

        oos   =   new   ObjectOutputStream(new   FileOutputStream(file));

        ois   =   new   ObjectInputStream(new   FileInputStream(file));

       

        或者网络流通道

        oos   =   new   ObjectOutputStream(socket.getOutputStream());

        ois   =   new   ObjectInputStream(socket.getInputStream());  

不知道大家是否注意到oos总是在ois之前定义，这里不希望大家误解这个顺序是固定的么？回答是否定的，那么有顺序要求么？回答是肯定的。原则是什么呢？

原则是互相对接的输入/输出流之间必须是output流先初始化然后再input流初始化，否则就会抛异常。大家肯定会问为什么？只要稍微看一看这两个类的源代码文件就大概知道了，output流的任务很简单，只要把对象转换成二进制往通道中写就可以了，但input流需要做很多准备工作来接受并最终重组这个Object，所以ObjectInputStream的构造函数中就需要用到output初始化发送过来的header信息，这个方法叫做   readStreamHeader()，它将会去读两个Short值用于决定用多大的缓存来存放通道发送过来的二进制流，这个缓存的size因jre的版本不同是不一样的。所以output如果不先初始化，input的构造函数首先就无法正确运行。

对于上面两个例子，第一个顺序是严格的，第二个因为oos和ois连接的已经不是对方了，而是socket另外一端的流，需要严格按照另外一方对接的output流先于对接的input流打开才能顺利运行。这个writeObject和readObject本身就是线程安全的，传输过程中是不允许被并发访问的。所以对象能一个一个接连不断的传过来，有很多人在运行的时候会碰到EOFException,   然后百思不得其解，去各种论坛问解决方案。其实笔者这里想说，这个异常不是必须声明的，也就是说它虽然是异常，但其实是正常运行结束的标志。EOF表示读到了文件尾，发送结束自然连接也就断开了。如果这影响到了你程序的正确性的话，请各位静下心来看看自己程序的业务逻辑，而不要把注意力狭隘的聚集在发送和接受的方法上。因为笔者也被这样的bug困扰了1整天，被很多论坛的帖子误解了很多次最后得出的教训。如果在while循环中去readObject，本质上是没有问题的，有对象数据来就会读，没有就自动阻塞。那么抛出EOFException一定是因为连接断了还在继续read，什么原因导致连接断了呢？一定是业务逻辑哪里存在错误，比如NullPoint、   ClassCaseException、ArrayOutofBound，即使程序较大也没关系，最多只要单步调适一次就能很快发现bug并且解决它。

难怪一位程序大师说过：解决问题90％靠经验，5％靠技术，剩下5％靠运气！真是金玉良言，笔者大概查阅过不下30篇讨论在while循环中使用   readObject抛出EOFExceptionde   的帖子，大家都盲目的去关注解释这个名词、反序列化的行为或反对这样写而没有一个人认为EOF是正确的行为，它其实很老实的在做它的事情。为什么大家都忽略了真正出错误的地方呢？两个字，经验！

关于Java的多线程编程

关于Java的线程，初学或者接触不深的大概也能知道一些基本概念，同时又会很迷惑线程到底是怎么回事？如果有人认为自己已经懂了不妨来回答下面的问题：

a.   A对象实现Runnable接口，A.start()运行后所谓的线程对象是谁？是A么？

b.   线程的wait()、notify()方法到底是做什么时候用的，什么时候用？

c.   为什么线程的suspend方法会被标注过时，不推荐再使用，线程还能挂起么？

d.   为了同步我们会对线程方法声明Synchronized来加锁在对象上，那么如果父类的f()方法加了Synchronized，子类重写f()方法必须也加Synchronized么？如果子类的f()方法重写时声明Synchronized并调用super.f()，那么子类对象上到底有几把锁呢？会因为竞争产生死锁么？

第一点，线程跟对象完全是两回事，虽然我们也常说线程对象。但当你用run()和start()来启动一个线程之后，线程其实跟这个继承了Thread或实现了Runnable的对象已经没有关系了，对象只能算内存中可用资源而对象的方法只能算内存正文区可以执行的代码段而已。既然是资源和代码段，另外一个线程当然也可以去访问，main函数执行就至少会启动两个线程，一个我们称之为主线程，还一个是垃圾收集器的线程，主线程结束就意味着程序结束，可垃圾收集器线程很可能正在工作。

第二点，wait()和sleep()类似，都是让线程处于阻塞状态暂停一段时间，不同之处在于wait会释放当前线程占有的所有的锁，而   sleep不会。我们知道获得锁的唯一方法是进入了Synchronized保护代码段，所以大家会发现只有Synchronized方法中才会出现   wait，直接写会给警告没有获得当前对象的锁。所以notify跟wait配合使用，notify会重新把锁还给阻塞的线程重而使其继续执行，当有多个对象wait了，notify不能确定唤醒哪一个，必经锁只有一把，所以一般用notifyAll()来让它们自己根据优先级等竞争那唯一的一把锁，竞争到的线程执行，其他线程只要继续wait。

从前Java允许在一个线程之外把线程挂起，即调用suspend方法，这样的操作是极不安全的。根据面向对象的思想每个对象必须对自己的行为负责，而对自己的权力进行封装。如果任何外步对象都能使线程被挂起而阻塞的话，程序往往会出现混乱导致崩溃，所以这样的方法自然是被毙掉了啦。

最后一个问题比较有意思，首先回答的是子类重写f()方法可以加Synchronized也可以不加，如果加了而且还内部调用了super.f ()的话理论上是应该对同一对象加两把锁的，因为每次调用Synchronized方法都要加一把，调用子类的f首先就加了一把，进入方法内部调用父类的   f又要加一把，加两把不是互斥的么？那么调父类f加锁不就必须永远等待已经加的锁释放而造

成死锁么？实际上是不会的，这个机制叫重进入，当父类的f方法试图在本对象上再加一把锁的时候，因为当前线程拥有这个对象的锁，也可以理解为开启它的钥匙，所以同一个线程在同一对象上还没释放之前加第二次锁是不会出问题的，这个锁其实根本就没有加，它有了钥匙，不管加几把还是可以进入锁保护的代码段，畅通无阻，所以叫重进入，我们可以简单认为第二把锁没有加上去。

总而言之，Synchronized的本质是不让其他线程在同一对象上再加一把锁。

Java中的RMI机制

RMI的全称是远程方法调用，相信不少朋友都听说过，基本的思路可以用一个经典比方来解释：A计算机想要计算一个两个数的加法，但A自己做不了，于是叫另外一台计算机B帮忙，B有计算加法的功能，A调用它就像调用这个功能是自己的一样方便。这个就叫做远程方法调用了。远程方法调用是EJB实现的支柱，建立分布式应用的核心思想。这个很好理解，再拿上面的计算加法例子，A只知道去call计算机B的方法，自己并没有B的那些功能，所以A计算机端就无法看到B执行这段功能的过程和代码，因为看都看不到，所以既没有机会窃取也没有机会去改动方法代码。EJB正式基于这样的思想来完成它的任务的。当简单的加法变成复杂的数据库操作和电子商务交易应用的时候，这样的安全性和分布式应用的便利性就表现出来优势了。   好了，回到细节上，要如何实现远程方法调用呢？我希望大家学习任何技术的时候可以试着依赖自己的下意识判断，只要你的想法是合理健壮的，那么很可能实际上它就是这么做的，毕竟真理都蕴藏在平凡的生活细节中。这样只要带着一些薄弱的Java基础来思考RMI，其实也可以想出个大概来。  

a)   需要有一个服务器角色，它拥有真正的功能代码方法。例如B，它提供加法服务  

b)   如果想远程使用B的功能，需要知道B的IP地址  

c)   如果想远程使用B的功能，还需要知道B中那个特定服务的名字  

我们很自然可以想到这些，虽然不完善，但已经很接近正确的做法了。实际上RMI要得以实现还得意于Java一个很重要的特性，就是Java反射机制。我们需要知道服务的名字，但又必须隐藏实现的代码，如何去做呢？答案就是：接口！  

举个例子：  

public   interface   Person(){  

public   void   sayHello();  

}  

 

Public   class<span