Java基础（一）

提问

• 谈谈你对 Java 最直观的印象是什么？是它宣传的 “Write once, run anywhere"？
• 谈谈你对 Java 平台的理解？
• Java 是解释执行，这句话正确吗？
• Exception 和 Error 有什么区别？
• 运行时异常和一般异常有什么区别？
• 你了解哪些常见的 Error，Exception，RuntimeException？
• NoClassDefFoundError 和 ClassNotFoundException 有什么区别？
• 异常处理的代码有哪些比较良好的规范？
• 谈谈 final、finally、finalize 有什么不同？
• 为什么局部内部类和匿名内部类只能访问局部final变量？

正文

谈谈你对 Java 平台的理解？

一看到这个问题时很懵，对 Java 平台的理解？这是啥问题，面这么广，该说些啥。

一瞬间闪过脑袋的，无外乎：面向对象的高级编程语言？跨平台？三大特性？然后就没了~

然后看了本讲的内容，浏览了评论区各大神的回答，才发现，自己的基础确实很薄弱。这个问题并没有固定的答案，但关键在于考核你对 Java 掌握的系统性？你自己有没有生成关于 Java 知识的大体框架？你是否对每个知识点有深入的了解过？

结合课程的内容和评论区大神的回复，我梳理出了大伙对于这个问题回答后的脑图，也算是在这门课程之后，我所学到的以及生成的对于 Java 知识点的一个大体的认识框架吧。

当然，这张系统性的知识框架肯定不全，在后续课程的学习中，我会渐渐来完善自己的这张知识框架体系。

1. 三大特性

Java 语言有三大特性：继承、封装、多态

继承

子类继承父类非私有的成员变量和成员方法。

final 声明的类不允许继承。

子类可通过 super 调用父类的有权限的方法。

父类有显示声明构造函数时，子类的构造函数中必须直接或间接的调用 super，另构造函数中使用 super 和 this 关键字必须在首行。

封装

这个特性更倾向于编程思想，将一些细节实现对外隐藏，通过权限控制，让外部仅需要与公开的接口打交道即可。

Java 有四种权限：包权限、私有权限、保护权限、公开权限

多态

多态：对象的多种形态

引用多态：父类对象可指向具体子类

方法多态：重写 & 重载

2. 语言特性

Java 语言有很多很多特性：泛型、反射、代理、并发、等等，每个特性我并不是很了解，所以只将目前自己较为熟悉的特性记录下来，其他特性留待后续慢慢完善。

泛型

• 类

泛型的使用： public class BaseView<T>{}

定义时类型限定： public class BaseView<T extend Object>{}

使用时类型限定： private void test(BaseView<? extend Object> o){}

• 方法参数

泛型的使用：public <T> void test(T t){}

类型限定： public <T extend Object> void test(T t){}

返回值泛型限定： public <T> T test(){}

反射

• 创建构造函数私有化的类对象

//1. 获取类的无参构造函数
//2. 设置访问权限
//3. 调用 newInstance，创建对象
Constructor<Test> constructor = Test.class.getDeclaredConstructor();
construcotr.setAccessible(true);
Test test = constructor.newInstance();

• 调用私有方法

//1. 先获取类对象
//2. 根据方法名和方法参数获取方法对象
//3. 设置访问权限
//4. 调用 invoke，传入类对象，调用私有方法
Test t = new Test();
Method method = Test.class.getDeclaredMethod("test");
method.setAccessible(true);
method.invoke(t);

• 改变私有属性

//1. 先获取类对象
//2. 根据变量名获取 Field 对象
//3. 设置访问权限
//4. 调用 Field 的 setXXX 方法，传入类对象，修改私有方法
Test t = new Test();
Field field = Test.class.getDeclaredField("m");
field.setAccessible(true);
field.setInt(t, 20);

3. JDK&JRE

最开始我只知道，JDK 是 Java 开发者开发所需要的工具，JRE 则是 Java 程序运行所需的运行环境。仅仅只知道这么多了，至于有哪些工具，运行环境又是些什么则不大清楚。

课程里则提到了对于这些最好也要能够深入了解，比如清楚 JDK 中的编译器：javac、sjavac，诊断工具：jmap、jstack、jconsole、jhsdb、jcmd，辅助工具：jlink、jar、jdeps 等等。

对于 JRE 需要清楚 JVM 虚拟机，虚拟机的一些特性：垃圾收集器、运行时、动态编译等等，运行环境的一些基本类库：集合、并发、网络、安全、线程、IO、NIO 等等，对于每个类库都要有所了解。

突然发现，一个简单的知识点，一旦深入的话，是可以挖掘出一大堆知识点的。

目前对于这块，我基本算是没接触，后续慢慢来完善这块的知识点，让自己构建一个系统化、体系化、牢固的知识框架。

4. JVM

Java 跨平台特性的基础其实是依赖于 JVM 虚拟机的，Java 语言本身并没有跨平台的特性，而是借助了 JVM 虚拟机。它就类似于一个中间件，将各个系统平台之间的差异隐藏掉，接收字节码。所以，只要将 Java 源程序编译成字节码，JVM 内部就会对字节码转换成各系统平台的可执行的机器码，做到"编译一次，到处运行"的特性。

而从 JVM 虚拟机这一点出发，可以挖掘出一系列的知识点：

• 内存管理，包括内存模型、常见的 GC、回收算法、内存泄漏、内存优化等等
• 类加载机制，包括双亲委派等等
• 解释执行与编译执行机制，包括 JIT、AOT 等等

每个点都可以单独开好几篇章来讲，现在也没有系统的掌握，对每个点都是零零散散的印象理解，同样也留待后续慢慢完善。

针对开头的问题引用原文回答一下：

对于“Java是解释执行”这句话，这个说法不太准确。我们开发的 Java的源代码，首先通过 Javac编译成为字节码（bytecode），然后，在运行时，通过 Java虚拟机（JVM）内嵌的解释器将字节码转换成为最终的机器码。但是常见的 JVM，比如我们大多数情况使用的 Oracle JDK提供的 Hospot JVM，都提供了 JIT（Just-In-Time）编译器，也就是通常所说的动态编译器，JIT能够在运行时将热点代码编译成机器码，这种情况下部分热点代码就属于编译执行，而不是解释执行了。

Exception

Exception 是程序正常运行时，可以预料到的意外情况，可以被捕获，也应该进行相应异常处理。

Exception 继承自 Throwable，具体又可划分为 RuntimeException 运行时异常和一般异常。两者的区别在于运行时异常在编译阶段可以不用进行捕获，这类异常通常都是在 Lint 检查过程中，或者程序运行期间才暴露出来的异常，因此也可以被归类为非检查型异常。

一般异常则是在编译期间就必须进行异常捕获，因此也被归类为检查型异常。

Error

Error 也是继承自 Throwable，同样会造成程序崩溃退出，但跟异常不大一样的是，这类错误问题，通常是由于 JVM 运行状态出了问题导致，我们不应捕获处理。要做的，应该是分析该错误出现的原因，尽量避免这类问题的出现。

关于 Exception 和 Error 的区别，可以简单这么理解，我们可以从异常中恢复程序但却不应该尝试从错误中恢复程序。

以上，基本就是我对于该讲问题所能想到的最大限度的点了。看了该讲作者所扩展的点，以及评论区里大神的回复，其实还可以从常见的一些异常，即原因和处理方式扩展；也可以从异常处理代码的规范角度出发扩展讲一讲，我都统一将这些扩展都在开头的提问中列出来了。

常见的 Exception 或 Error

想查阅相关的 Exception 或 Error，如果你记得该异常的名称，那可以直接通过 Android Stduio 查阅相关源码即可。

如果想翻看所有的类别，那么也可通过 AS 的 Hierarchy 功能查阅，快捷键 Ctrl + H，如下：

在这里翻看、过滤你熟悉的，或者想找的异常或错误，点进去查看相关源码说明即可。

至于常见的 Exception，RuntiomeException，Error，我针对个人在项目中较常遇见，目前印象较深的画了张类图：

• ActivityNotFoundException

源码注释里说了，该异常是当调用了 startActivity() 之后，找不到匹配的 Activity 时抛出该异常。也就是说，通常通过隐式 Intent 打开 Activity，或者通过广播，URI 等方式，不注意一点的话，可能会出现该异常。

如果有使用到这些场景，可以考虑是否增加异常捕获，防止使用不当造成异常。

• BadTokenException

这里的异常指的是 WindowManager 内部类 BadTokenException，显然，当添加一个新的 window 时，如果 LayoutParams 不合法，就会抛出该异常。

添加 window 的场景，除了手动通过 WindowManager 的 addView() 的场景外，其实打开一个新的 Activity，新的 Dialog，内部也是通过 WindowManager 来 addView() 的，因此，这些场景下都是有可能发生该异常的。

不过，这个异常的日志会比较详细，因为在 ViewRootImpl 的 setView() 中，会去细分参数不合法的类别，附上部分源码：

//ViewRootImpl#setView()

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
    switch (res) {
            case WindowManagerGlobal.ADD_BAD_APP_TOKEN:
            case WindowManagerGlobal.ADD_BAD_SUBWINDOW_TOKEN:
                throw new WindowManager.BadTokenException(
                        "Unable to add window -- token " + attrs.token
                                + " is not valid; is your activity running?");
            case WindowManagerGlobal.ADD_NOT_APP_TOKEN:
                throw new WindowManager.BadTokenException(
                        "Unable to add window -- token " + attrs.token
                                + " is not for an application");
            case WindowManagerGlobal.ADD_APP_EXITING:
                throw new WindowManager.BadTokenException(
                        "Unable to add window -- app for token " + attrs.token
                                + " is exiting");
            case WindowManagerGlobal.ADD_DUPLICATE_ADD:
                throw new WindowManager.BadTokenException(
                        "Unable to add window -- window " + mWindow
                                + " has already been added");
            case WindowManagerGlobal.ADD_STARTING_NOT_NEEDED:
                // Silently ignore -- we would have just removed it
                // right away, anyway.
                return;
            case WindowManagerGlobal.ADD_MULTIPLE_SINGLETON:
                throw new WindowManager.BadTokenException("Unable to add window "
                        + mWindow + " -- another window of type "
                        + mWindowAttributes.type + " already exists");
            case WindowManagerGlobal.ADD_PERMISSION_DENIED:
                throw new WindowManager.BadTokenException("Unable to add window "
                        + mWindow + " -- permission denied for window type "
                        + mWindowAttributes.type);
}

• ClassCastException

父类可以通过强制类型转换成具体某个子类，但如果强转的两个类之间不存在继承关系，那么就会抛出该异常。

如果不确定需要强转的两个类的关系，可以先通过关键字 instanceof 进行判断。

• ConcurrentModificationException

这异常则是由于一些不恰当的集合操作导致，比如遍历集合的过程中，进行了不恰当的删除操作；或者有某个线程正在遍历集合，另外一个线程则对该集合进行的修改操作；

相对应的避免方法网上也很多，比如遍历集合删除的操作通过迭代器来实现等等。

• IndexOutOfBoundsException

数组越界异常，这类异常还蛮经常出现的，避免方式就只能是尽量书写规范的代码，注意一些，或者多让程序跑跑 Lint 检查。

• NullPointerException

空指针异常，这异常算是最令人头疼的异常了，在线上异常的比例中，肯定不少。

而且出现情况有时还很难分析，代码流程上查看，明明不会出现空指针场景，但现实就是有用户的的确确出现了。

解决时，如果可以，尽量不要简单的加个非空判断，在程序中各个地方加非空判断，其实是种特别不优雅的行为。如果能明确为什么会出现为空的场景，如何解决，这是最好的，而不是每次都简单的加个非空判断。

场景很多很多，之前也有写过一篇专门处理实体类的空判断文章，感兴趣的可以看看：

分享两个提高效率的AndroidStudio小技巧

• IOException

IO 异常，属于检查型异常，必须通过 try catch 代码块捕获才能通过编译阶段，这也就没什么好介绍的了。

• OutOfMemoryError

内存溢出错误，这类问题属于 Error，不属于 Exception，所以不要期待解决这类问题仅仅通过捕获就可以处理。

针对 Error 这类问题，我们没法捕获处理，只能是从避免的角度出发，分析出现的原因，尽量不用出现这类问题。

造成内存溢出的问题，有多种，大概就是图片问题、内存泄漏问题。

针对图片使用的优化处理，网上很多，各种压缩、降分辨率等等方式。

针对内存泄漏，一是开发期间遵守规范的代码行为，尽量避免写出有内存泄漏的隐患；二是发生内存泄漏后，借助相应工具进行定位分析。

• StackOverflowError

这类错误很严重，表示程序陷入了死循环当中，原因也就是你写了有问题的代码。

因此，当出现这类问题，最好尽快定位处理。

• NoClassDefFoundError

这类问题，通常出现的场景是：编译阶段没问题，但程序运行期间却出现该问题。

原因一般是由于打包时，jar 出现问题，部分类没有打包进去，导致的问题。

• ClassNotFoundException

这个异常，同样属于相关类找不到的问题，但出现的场景通常是由于程序中使用了反射，或者动态加载之类的方式，使用了错误的类名，导致的问题。

还有可能是由于混淆导致。

异常处理良好规范

• 尽量不要捕获类似 Exception 这样通用的异常，而是应该捕获特定异常

这是因为在日常的开发和合作中，我们读代码的机会往往超过写代码，软件工程是门协作艺术，所以我们有义务让自己的代码能够直观的体现出尽量多的信息，而泛泛的 Exception 之类，恰恰隐藏了我们的目的。另外，我们也要保证程序不会捕获到我们不希望捕获的异常。比如，你可能更希望 RuntimeException 被扩散出来，而不是被捕获。

进一步讲，除非深思熟虑了，否则不要捕获 Throwable 或者 Error，这样很难保证我们能够正确处理异常。

• 不要生吞异常

如果我们不把异常抛出来，或者也没有输出到日志之类，程序可能在后续代码以不可控的方式结束。没人能够轻易判断究竟是哪里抛出了异常，以及是什么原因产生了异常。

• try-catch 代码段会产生额外的性能开销

try-catch 代码段往往会影响 JVM 对代码进行优化，所以建议仅捕获有必要的代码段，尽量不要一个大的 try 包住整段的代码；与此同时，利用异常控制代码流程，也不是一个好主意，远比我们通常意义上的条件语句 （if / else, switch）要低效

Java 每实例化一个 Exception，都会对当时的栈进行快照，这是一个相对比较重的操作，如果发生的非常频繁，这个开销可就不能被忽略了。

• 不要在 finally 代码块中处理返回值

按照我们程序员的惯性认知：当遇到 return 语句的时候，执行函数会立刻返回。但是，在 Java 语言中，如果存在 finally 就会有例外。除了 return 语句， try 代码块中的 break 或 continue 语句也可能使控制权进入 finally 代码块。

请勿在 try 代码块中调用 return, break, continue 语句。万一无法避免，一定要确保 finally 的存在不会改变函数的返回值。

函数的返回值有两种类型：值类型和对象引用，对于对象引用，要特别小心，如果在 finally 代码块中对函数返回的对象成员属性进行了修改，即使不在 finally 块中显示调用 return 语句，这个修改也会作用于返回值上。

• 当一个 try 后跟了很多个 catch 时，必须先捕获小的异常再捕获大的异常。

final

final 是 java 中的关键字，可用于修饰类，方法，变量。

当修饰类时，表明这个类不可被继承。Java 中有一些核心类都被 final 修饰了，比如 String，System。当考虑到安全性原因时，可以将该类设计成 final。

当修饰方法时，表明该方法不可被重写。一般是某些流程控制不希望被修改掉时，可以将这些方法声明成 final，比如 View 中的 measure()，requestFocus()，findViewById()。

当修饰变量时，表明该变量为常量，不允许被重新赋值，因此声明成 final 的变量都需要显示的进行赋值，否则编译会报错。

finally

finally 是确保 try-catch 方式最后执行的一种机制，通常的用法都是在 finally 里进行一些资源的关闭，回收。比如 IO 流的关闭等等。

建议最好不要利用 finally 来控制流程，也不要在 finally 中有返回值，否则很容易影响正常流程，导致流程结构特别杂乱。

另外，有些特殊情况下，finally 中的代码并不会被执行到，比如：

//1.try-catch异常退出
try {
    System.exit(1)
} catch {
    ....
} finally {
    //不会执行到这里
    Log.d("finally", "finally");
}

//2.无限循环
try {
    while(true) {
        ...
    }
} finally {
    //不会执行到这里
    Log.d("finally", "finally");
}

//3. 线程被杀死
//当执行 try-catch 时，线程被杀死了，那么 finally 里的代码也无法被执行到

总之，finally 通常情况下都会最后被执行到，所以最好不要在这里有 return 之类的语句来影响正常流程。但在某些特殊的场景下，finally 并不会被执行到，了解一下即可。

finalize

这个是 Object 中的一个方法，方法注释说了很多，大概就是讲这个方法是由垃圾收集器即将要回收该对象时会调用该方法，用户可在这里做一些最后的资源释放工作。

以上是概念定义，但说实话，没用过该方法，而且作者也说了，不推荐使用 finalize 机制来做资源回收，并且在 JDK 9，这个方法已经被标志为 deprecated 废弃的方法了。

作者有提到说，因为我们无法保证 finalize 什么时候执行，执行是否符合预期，使用不当还会影响性能，导致程序死锁、挂起等问题。

那么，有其他方案来替代 finalize 处理回收资源的工作么？有，Cleaner 机制，这个我没接触过，作者提了这个替代方案。另外，作者也说了，回收资源最好就是资源用完后就随手清除，或者结合 try-catch-finally 机制回收。不管是 finalize 或者 Cleaner 机制，最好都只将它看成是最后一道防线，一旦将主要的回收工作依赖于这两个机制的话，很容易出现各种问题。

扩展

为什么局部内部类和匿名内部类只能访问局部final变量？

先来看这么段代码：

//参数 msg 必须声明为 final 类型
public void notifyChange(final String msg) {
    mTextView.post(new Runnable() {
        @Override
        public void run() {
            mTextView.setText(msg);
        }
    })
}

在这里，post() 方法的参数是一个匿名内部类，在内部类中如果要使用外部 notifyChange() 方法的参数 msg，那么必须将 msg 类型声明成 final，否则编译器会保错。

这种场景非常常见的吧，不管是类似上述的 Ui 场景，还有网络访问时也经常需要通过回调通知上层，此时也就经常出现这种场景了。

那么，有考虑过，为什么内部类只能访问局部 final 变量么？

如果懂得反编译 class 文件的，那么应该就很清楚了。我也不懂，理解这点是通过阅读其他大神分析的文章，以下是我的理解：

首先，变量都是有生命周期的，成员变量的生命周期就跟随着对象的整个生命周期，而局部变量的生命周期则是非常有限。

比如方法内部的局部变量，它的生命周期就是在这个方法执行结束就终止。同样，方法的参数也是局部变量，它是生命周期也同样是到该方法执行结束。

另外，内部类的执行时机有时是会在外部方法执行结束之后。就拿上述例子来说，post() 中 Runnable 的执行时机，肯定是在外部 notifyChange() 方法执行完之后的。

那么，问题来了。内部类 Runnable 的执行需要使用到外部方法 notifyChange() 的参数，但当它执行的时候，这个参数的生命周期早已结束，已经被回收掉了。既然已经被回收了，内部类又是怎么使用外部的这个局部变量呢？

有大神反编译了 class 文件后，给出了结论，原来内部类使用外部的局部变量时，是通过 copy 一份过来。也就是说，其实内部类此时使用的是自己内部定义的局部变量了，只是这个变量的值是复制外部那个局部变量的而已。

这也就解释了，为什么外部的局部变量明明已经被回收了，内部类仍旧可以使用，因为内部类此时使用的并不是外部类的局部变量引用了。

但到这里，新的问题就来了：既然内部类使用的局部变量本质上跟外部的局部变量是相互独立的两个变量，那如果在内部类中修改了这个局部变量的值会出现什么情况？是吧，数据的不一致性。

基于此，java 编译器就直接限定死，内部类使用外部的局部变量时，必须将其限制为 final 类型，确保该变量不允许进行更改。

这样一来，其实也就顺便理解了，为什么成员变量可以直接在内部类中使用，因为成员变量的声明周期很长，不存在局部变量的问题。

以上内容，是在大神的文章里被醍醐灌顶了，感谢大神，原文链接放出来：

Java内部类详解