000_必须明白的六个 JAVA 问题

Rambo 2020年05月24日 285次浏览

介绍声明

  这些问题对于认真学习 JAVA 的人来说都是必须掌握的,当然如果你只是初学者就没必要那么严格了,那如果你认为自己已经超越初学者的范畴,却不是很懂这些问题,请将你自己重归于初学者行列。

一、到底要怎么样初始化

本问题讨论变量的初始化,所以先来看一下 JAVA 中有哪些种类的变量

  1. 类的属性(值域)

  2. 方法里的局部变量

  3. 方法的参数

  对于第一种变量(类的属性),JAVA 虚拟机会自动进行初始化。如果给出了初始值,则初始化为该初始值。如果没有给出,则把它初始化为该类型变量的默认初始值。所有对象引用类型变量默认初始值为 null,即不指向任何对象。注意数组本身也是对象,所以没有初始化的数组引用在自动初始化后其值也是 null

  对于两种不同的类属性,static 属性与 instance 属性,初始化的时机是不同的。instance 属性在创建实例的时候初始化。static 属性在类加载,也就是第一次用到这个类的时候初始化,对于后来的实例的创建,不再次进行初始化。对于第二种变量,必须明确地进行初始化。如果在没有初始化之前就试图使用它,编译器会抗议。如果初始化的语句在 try 块中或 if 块中,也必须要让它在第一次使用前一定能够得到赋值。也就是说,把初始化语句放在只有 if 块的条件判断语句中编译器也会抗议,因为执行的时候可能不符合 if 后面的判断条件,如此一来初始化语句就不会被执行了,这就违反了局部变量使用前必须初始化的规定。但如果在 else 块中也有初始化语句,就可以通过编译,因为无论如何,总有至少一条初始化语句会被执行,不会发生使用前未被初始化的事情。对于 try-catch 也是一样,如果只有在 try 块里才有初始化语句,编译不通过。如果在 catchfinally 里也有,则可以通过编译。

  总之,要保证局部变量在使用之前一定被初始化。所以,一个好的做法是在声明他们的时候就初始化它们。如果不知道要初始化成什么值好,就用上面的默认值吧!其实第三种变量和第二种本质上是一样的,都是方法中的局部变量。只不过作为参数,肯定是被初始化过的,传入的值就是初始值,所以不需要初始化。

二、instanceof 是什么

   instanceofJAVA 的一个二元操作符,和 ==>< 是同一类东西。由于它是由字母组成的,所以也是 JAVA 的保留关键字,它的作用是测试它左边的对象是否是它右边的类的实例,返回 boolean 类型的数据。然而,这种做法通常被认为是没有好好利用面向对象中的多态性。其实上面的功能要求用方法重载完全可以实现,这是面向对象变成应有的做法,避免回到结构化编程模式。只要提供两个名字和返回值都相同,接受参数类型不同的方法就可以了。所以,使用 instanceof 在绝大多数情况下并不是推荐的做法,应当好好利用多态

三、"==" 和 "equals" 方法究竟有什么区别

String a = new String("foo");
String b = new String("foo");

  == 操作符专门用来比较变量的值是否相等。比较好理解的一点是:对象变量其实是一个引用,它们的值是指向对象所在的内存地址,而不是对象本身。 ab 都使用了 new 操作符,意味着将在内存中产生两个内容为 foo 的字符串,既然是 "两个" ,它们自然位于不同的内存地址。ab 的值其实是两个不同的内存地址的值。所以使用 == 操作符,结果会是 false 。诚然, ab 所指的对象,它们的内容都是 foo ,应该是 "相等" ,但是 == 操作符并不涉及到对象内容的比较,对象内容的比较,正是 equals 方法做的事。

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    if (anObject instanceof String) {
        String anotherString = (String)anObject;
        int n = value.length;
        if (n == anotherString.value.length) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = 0;
            while (n-- != 0) {
                if (v1[i] != v2[i])
                    return false;
                i++;
            }
            return true;
        }
    }
    return false;
}

下面再来看一下 Object 对象的 equals 方法是如何实现的:

boolean equals(Object o){
  return this == o;
}

   Object 对象默认使用了 == 操作符,所以如果你自创的类没有覆盖 equals 方法,那你的类使用 equals 和使用 == 会得到同样的结果。同样也可以看出,Objectequals 方法没有达到 equals 方法应该达到的目标:比较两个对象内容是否相等。因为答案应该由类的创建者决定,所以 Object 把这个任务留给了类的创建者。所以当你是用 equals 方法判断对象的内容是否相等,请不要想当然,因为可能你认为相等,而这个类的作者不这样认为,而类的 equals 方法的实现是由他掌握的。如果你需要使用 equals 方法,或者使用任何基于散列码的集合( HashSet、HashMap、HashTable ),请察看一下 java doc 以确认这个类的 equals 逻辑是如何实现的。

四、final 关键字到底修饰了什么

   final 使得被修饰的变量 "不变",但是由于对象型变量的本质是 "引用",使得 "不变" 也有了两种含义:引用本身的不变和引用指向的对象不变。

引用本身的不变:

final StringBuffer a = new StringBuffer("immutable");
final StringBuffer b = new StringBuffer("not immutable");
// 编译期错误
a = b;

引用指向的对象不变:

final StringBuffer a = new StringBuffer("immutable");
// 编译通过
a.append("broken!");

  可见,final 只对引用的 "值" 有效,它迫使引用只能指向初始指向的那个对象,改变它的指向会导致编译期错误。至于它所指向的对象的变化,final 是不负责的。这很类似 == 操作符, == 操作符只负责引用的 "值" 相等。至于这个地址所指向的对象内容是否相等, == 操作符是不管的。理解 final 问题有很重要的含义。许多程序漏洞都基于此处, final 只能保证引用永远指向固定对象,不能保证那个对象的状态不变。在多线程的操作中,一个对象会被多个线程共享或修改,一个线程对对象无意识的修改可能会导致另一个使用此对象的线程崩溃。一个错误的解决方法就是在此对象新建的时候把它声明为 final ,意图使得它 "永远不变"。其实那是徒劳的。

五、我声明了什么

String s = "Hello world!";

  许多人都做过这样的事情,但是,我们到底声明了什么?回答通常是:一个 String ,内容是 "Hello world!" 。这样模糊的回答通常是概念不清的根源。如果要准确的回答,一半的人大概会回答错误。这个语句声明的是一个指向对象的引用,名为 s ,可以指向类型为 String 的任何对象,目前指向 "Hello world!" 这个 String 类型的对象。这就是真正发生的事情。我们并没有声明一个 String 对象,我们只是声明了一个只能指向 String 对象的引用变量。所以,如果在刚才那句语句后面,如果再运行一句: String string = s; 我们是声明了另外一个只能指向 String 对象的引用。名为 String ,并没有第二个对象产生,String 还是指向原来那个对象,也就是和 s 指向同一个对象。

六、String到底变了没有

没有。

  因为 String 被设计成不可变(immutable)类,所以它的所有对象都是不可变对象。请看下列代码:

String s = "Hello";
s = s + " world!";

  s 所指向的对象是否改变了呢?我们来看看发生了什么事情,在这段代码中,s 原先指向一个 String 对象内容是 "Hello",然后我们对 s 进行了 + 操作,那么 s 所指向的那个对象是否发生了改变呢?答案是没有。这时 s 不指向原来那个对象了,而指向了另一个 String 对象,内容为 "Hello world!" 。原来那个对象还存在于内存之中,只是 s 这个引用变量不再指向它了。通过上面的说明,我们很容易得出另一个结论,如果经常对字符串进行各种各样的修改,或者说,不可预见的修改,那么使用 String 来代表字符串的话会引起很大的内存开销。因为 String 对象建立之后不能再改变,所以对于每一个不同的字符串,都需要一个 String 对象来表示。这时,应该考虑使用 StringBuffer 类,它允许修改,而不是每个不同的字符串都要生成一个新的对象。并且,这两种类的对象转换十分容易。同时,我们还可以知道,如果要使用内容相同的字符串,不必每次都 new 一个 String。例如我们要在构造器中对一个名叫 sString 引用变量进行初始化,把它设置为初始值,应当这样做:

public class Demo {
    private String s;
    public Demo() {
        s = "Initial Value";
    }
}

而非

s = new String("Initial Value");

  后者每次都会调用构造器,生成新对象,性能低下且内存开销大,并且没有意义,因为 String 对象不可改变,所以对于内容相同的字符串,只要一个 String 对象来表示就可以了。也就说,多次调用上面的构造器创建多个对象,他们的 String 类型属性 s 都指向同一个对象。

  上面的结论还基于这样一个事实:对于字符串常量,如果内容相同,JAVA 认为它们代表同一个 String 对象。而用关键字 new 调用构造器,总是会创建一个新的对象,无论内容是否相同。至于为什么要把 String 类设计成不可变类,是它的用途决定的。其实不只 String,很多 JAVA 标准类库中的类都是不可变的。在开发一个系统的时候,我们有时候也需要设计不可变类,来传递一组相关的值,这也是面向对象思想的体现。不可变类有一些优点,比如因为它的对象是只读的,所以多线程并发访问也不会有任何问题。当然也有一些缺点,比如每个不同的状态都要一个对象来代表,可能会造成性能上的问题。所以 JAVA 标准类库还提供了一个可变版本,即 StringBuffer