读书笔记：《On Java 8》

女友杨超越

已于 2023-05-11 17:31:52 修改

阅读量503

点赞数

分类专栏：我的面试准备文章标签： java jvm 开发语言

于 2023-04-13 21:44:30 首次发布

本文链接：https://blog.csdn.net/qq_36491095/article/details/130138821

版权

我的面试准备专栏收录该内容

9 篇文章 0 订阅

订阅专栏

大佬推荐下开始看这本书，希望不会太晚，记录下自己的收获吧。

第三章

关于创建对象

代码String s创建的其实是String对象的引用，这也就解释了为什么直接用会出错，因为根本没有给变量s赋值也就是s没有指向任何的对象，应该创建引用同时初始化。
代码String s = new String("abcd") 用new来创建一个新的对象实例。

基本类型的存储因为使用频率很高，就不需要用new来创建，使用一个“自动”变量，这个变量直接存储“值”，存在栈内存中，更高效。

创建对象数组时候，实际上是在创建了一个引用数组，并且每个引用的初始值都为null。

当我们使用 new 关键字来创建 Java 对象时，它的生命周期将会超出作用域。比如这段代码

{
    String s = new String("a string");
} 
// 作用域终点

上例中，引用 s 在作用域终点就结束了。但是，引用 s 指向的字符串对象依然还在占用内存。在这段代码中，我们无法在这个作用域之后访问这个对象，因为唯一对它的引用 s 已超出了作用域的范围（这也是GC需要处理的）。

默认值的赋予并不适用于局部变量，这也就是为什么在方法中直接int x 会报错。比如在方法中直接这样定义int x。

关于static

通常来说，只有在使用new创建类的对象后，数据存储空间才被分配，对象的方法才能够供外界调用。这种方式在两种情况下是不足的。
1.有时候只想为特定字段分配一个共享存储空间，而不去考察究竟要创造多少对象、甚至根本就不创建对象
2.创建一个与此类的任何对象无关的方法。就是说没有创建对象，也可以调用该方法
static 关键字（从 C++ 采用）就符合上述两点要求。当我们说某个事物是静态时，就意味着该字段或方法不依赖于任何特定的对象实例。即使我们从未创建过该类的对象，也可以调用其静态方法或访问其静态字段。相反，对于普通的非静态字段和方法，我们必须要先创建一个对象并使用该对象来访问字段或方法。
可以通过类名直接引用静态对象。列如：

class StaticTest {
    static int i = 47;
}

即使创建了两个 StaticTest 对象，但是静态变量 i 仍只占一份存储空间。两个对象都会共享相同的变量 i。代码示例：

StaticTest st1 = new StaticTest();
StaticTest st2 = new StaticTest();

st1.i 和 st2.i 指向同一块存储空间，因此它们的值都是 47。引用静态变量有两种方法。在前面的示例中，我们通过一个对象来定位它，例如 st2.i。我们也可以通过类名直接引用它，这种方式对于非静态成员则不可行

StaticTest.i++;

++ 运算符将会使变量结果 + 1。此时 st1.i 和 st2.i 的值都变成了 48。
使用类名直接引用静态变量是首选方法，因为它强调了变量的静态属性。

第四章

第四章运算符先跳过。。。

第五章

第五章控制流也跳过。。。

第六章

关于构造器

关于构造器，通过构造器可以保证每个对象的初始化，如果一个类有构造器，那么 Java 会在用户使用对象之前（即对象刚创建完成）自动调用对象的构造器方法，从而保证初始化。Java 中使用了与C++同样的方式：构造器名称与类名相同（第一个是任何命名都可能与类中其他已有元素的命名冲突；第二个是编译器必须始终知道构造器方法名称，从而调用它，这两个问题通过同名的方法都得到了解决）。

关于重载

重载只能通过方法名和参数列表区分方法，不能通过返回值来进行区分，因为直接调用一个f()，Java编译器不知道到底想调用哪个方法读者也不明白所以就不能通过返回值来区分。

关于this关键字

this 关键字只能在非静态方法内部使用。当你调用一个对象的方法时，this 生成了一个对象引用。你可以像对待其他引用一样对待这个引用。
这是一段很常见的代码，即调用函数：

public class Apricot {
    void pick() {
        /* ... */
    }

    void pit() {
        pick();
        /* ... */
    }
}

其实，如果你在一个类的方法里调用其他该类中的方法，不要使用 this，直接调用即可，this 自动地应用于其他方法上了。也就是pit()的方法中，使用this.pick()，但是没必要，编译器自动帮你做这些。this 关键字只用在一些必须显式使用当前对象引用的特殊场合。

通常当你说 this，意味着"这个对象"或"当前对象"，它本身生成对当前对象的引用。在一个构造器中，当你给 this 一个参数列表时，它是另一层意思。它通过最直接的方式显式地调用匹配参数列表的构造器。这也是在构造器中this的另外一种用法：参数列表中的变量名 s 和成员变量名 s 相同，会引起混淆。你可以通过 this.s 表明你指的是成员变量 s，从而避免重复。

由this的理解深入到static的理解

理解了this的作用后，就加深对static的理解了，static 方法中不会存在 this，毕竟你不能在静态方法中调用非静态方法（反之可以）何况静态方法是为类而创建的，不需要任何对象。事实上，这就是静态方法的主要目的，静态方法看起来就像全局方法一样，但是 Java 中不允许全局方法，一个类中的静态方法可以被其他的静态方法和静态属性访问。使用静态方法，因为不存在 this，所以你没有向一个对象发送消息。

关于垃圾回收以及finalize()方法

关于垃圾回收，只要程序没有濒临内存用完的那一刻，对象占用的空间就总也得不到释放。如果程序执行结束，而垃圾回收器一直没有释放你创建的任何对象的内存，则当程序退出时，那些资源会全部交还给操作系统。这个策略是恰当的，因为垃圾回收本身也有开销，要是不使用它，那就不用支付这部分开销了。

毕竟在写代码时候，谁会清理一个int呢？但是使用完一个对象就不管它并非总是安全的。Java 中有垃圾回收器回收无用对象占用的内存。但现在考虑一种特殊情况：你创建的对象不是通过 new 来分配内存的，而垃圾回收器只知道如何释放用 new 创建的对象的内存，所以它不知道如何回收不是 new 分配的内存。为了处理这种情况，Java 允许在类中定义一个名为 finalize() 的方法。它的工作原理"假定"是这样的：当垃圾回收器准备回收对象的内存时，首先会调用其 finalize() 方法，并在下一轮的垃圾回收动作发生时，才会真正回收对象占用的内存。

这也就是为什么我经常看到类里面写了一个finalize()方法但是却没有显示的调用的原因。这意味着在你不再需要某个对象之前，如果必须执行某些动作，你得自己去做。Java 没有析构器或类似的概念，所以你必须得自己创建一个普通的方法完成这项清理工作。例如，对象在创建的过程中会将自己绘制到屏幕上。如果不是明确地从屏幕上将其擦除，它可能永远得不到清理。如果在 finalize() 方法中加入某种擦除功能，那么当垃圾回收发生时，finalize() 方法被调用（不保证一定会发生），图像就会被擦除，要是"垃圾回收"没有发生，图像则仍会保留下来。

无论是"垃圾回收"还是"终结"，都不保证一定会发生。如果 Java 虚拟机（JVM）并未面临内存耗尽的情形，它可能不会浪费时间执行垃圾回收以恢复内存。

finalize另外一个用法：对象终结条件的验证

当对某个对象不感兴趣时——也就是它将被清理了，这个对象应该处于某种状态，这种状态下它占用的内存可以被安全地释放掉。例如，如果对象代表了一个打开的文件，在对象被垃圾回收之前程序员应该关闭这个文件。只要对象中存在没有被适当清理的部分，程序就存在很隐晦的 bug。finalize() 可以用来最终发现这个情况，尽管它并不总是被调用。如果某次 finalize() 的动作使得 bug 被发现，那么就可以据此找出问题所在——这才是所真正关心的。

// housekeeping/TerminationCondition.java
// Using finalize() to detect a object that
// hasn't been properly cleaned up

import onjava.*;

class Book {
    boolean checkedOut = false;

    Book(boolean checkOut) {
        checkedOut = checkOut;
    }

    void checkIn() {
        checkedOut = false;
    }

    @Override
    protected void finalize() throws Throwable {
        if (checkedOut) {
            System.out.println("Error: checked out");
        }
        // Normally, you'll also do this:
        // super.finalize(); // Call the base-class version
    }
}

public class TerminationCondition {

    public static void main(String[] args) {
        Book novel = new Book(true);
        // Proper cleanup:
        novel.checkIn();
        // Drop the reference, forget to clean up:
        new Book(true);
        // Force garbage collection & finalization:
        System.gc();
        new Nap(1); // One second delay
    }

}

输结果Error: checked out。本例的终结条件是：所有的 Book 对象在被垃圾回收之前必须被登记。但在 main() 方法中，有一本书没有登记。要是没有 finalize() 方法来验证终结条件，将会很难发现这个 bug。

其中，@Override。@ 意味着这是一个注解，注解是关于代码的额外信息。在这里，该注解告诉编译器这不是偶然地重定义在每个对象中都存在的 finalize() 方法——程序员知道自己在做什么。编译器确保你没有拼错方法名，而且确保那个方法存在于基类中。注解也是对读者的提醒，@Override 在 Java 5 引入，在 Java 7 中改善。

关于垃圾回收

（这部分肯定是要看周志明的书再搞懂的，先理解下思想吧）

首先有一点，Java 从堆空间分配的速度可以和其他语言在栈上分配空间的速度相媲美。

例如，你可以把 C++ 里的堆想象成一个院子，里面每个对象都负责管理自己的地盘。一段时间后，对象可能被销毁，但地盘必须复用。在某些 Java 虚拟机中，堆的实现截然不同：它更像一个传送带，每分配一个新对象，它就向前移动一格。这意味着对象存储空间的分配速度特别快。Java 的"堆指针"只是简单地移动到尚未分配的区域，所以它的效率与 C++ 在栈上分配空间的效率相当。自然这种通过移动分配的方式速度很快。

但是这种方式也有明显的问题，Java 中的堆并非完全像传送带那样工作。要是那样的话，势必会导致频繁的内存页面调度——将其移进移出硬盘，因此会显得需要拥有比实际需要更多的内存。页面调度会显著影响性能。最终，在创建了足够多的对象后，内存资源被耗尽。其中的秘密在于垃圾回收器的介入。当它工作时，一边回收内存，一边使堆中的对象紧凑排列，这样"堆指针"就可以很容易地移动到更靠近传送带的开始处，也就尽量避免了页面错误，也就减小其对空间分配速度的影响。垃圾回收器通过重新排列对象，实现了一种高速的、有无限空间可分配的堆模型。

为了进一步了解Java的垃圾回收机制，先得了解其它系统中的垃圾回收机制会很有帮助。一种简单但速度很慢的垃圾回收机制叫做引用计数。每个对象中含有一个引用计数器，每当有引用指向该对象时，引用计数加 1。当引用离开作用域或被置为 null 时，引用计数减 1。因此，管理引用计数是一个开销不大但是在程序的整个生命周期频繁发生的负担。垃圾回收器会遍历含有全部对象的列表，当发现某个对象的引用计数为 0 时，就释放其占用的空间（但是，引用计数模式经常会在计数为 0 时立即释放对象）。这个机制存在一个缺点：如果对象之间存在循环引用，那么它们的引用计数都不为 0，就会出现应该被回收但无法被回收的情况。对垃圾回收器而言，定位这样的循环引用所需的工作量极大。引用计数常用来说明垃圾回收的工作方式，但似乎从未被应用于任何一种 Java 虚拟机实现中。

public class ReferenceCountingGc {
    Object instance = null;
    public static void main(String[] args) {
        ReferenceCountingGc objA = new ReferenceCountingGc();
        ReferenceCountingGc objB = new ReferenceCountingGc();
        objA.instance = objB;
        objB.instance = objA;
        objA = null;
        objB = null;
    }
}

代码所示：除了对象 objA 和 objB 相互引用着对方之外，这两个对象之间再无任何引用。但是他们因为互相引用对方，导致它们的引用计数器都不为 0，于是引用计数算法无法通知 GC 回收器回收他们。

在更快的策略中，垃圾回收器并非基于引用计数。它们依据的是：对于任意"活"的对象，一定能最终追溯到其存活在栈或静态存储区中的引用。这个引用链条可能会穿过数个对象层次，由此，如果从栈或静态存储区出发，遍历所有的引用，你将会发现所有"活"的对象。对于发现的每个引用，必须追踪它所引用的对象，然后是该对象包含的所有引用，如此反复进行，直到访问完"根源于栈或静态存储区的引用"所形成的整个网络。你所访问过的对象一定是"活"的。注意，这解决了对象间循环引用的问题，这些对象不会被发现，因此也就被自动回收了。

关于初始化的顺序

在类中变量定义的顺序决定了它们初始化的顺序。即使变量定义散布在方法定义之间，它们仍会在任何方法（包括构造器）被调用之前得到初始化。例如：

class Window {
    Window(int marker) {
        System.out.println("Window(" + marker + ")");
    }
}

class House {
    Window w1 = new Window(1); // Before constructor

    House() {
        // Show that we're in the constructor:
        System.out.println("House()");
        w3 = new Window(33); // Reinitialize w3
    }

    Window w2 = new Window(2); // After constructor

    void f() {
        System.out.println("f()");
    }

    Window w3 = new Window(3); // At end
}

public class OrderOfInitialization {
    public static void main(String[] args) {
        House h = new House();
        h.f(); // Shows that construction is done
    }
}

这里的输出是：

Window(1)
Window(2)
Window(3)
House()
Window(33)
f()

在 House 类中，故意把几个 Window 对象的定义散布在各处，以证明它们全都会在调用构造器或其他方法之前得到初始化。此外，w3 在构造器中被再次赋值。

由输出可见，引用 w3 被初始化了两次：一次在调用构造器前，一次在构造器调用期间（第一次引用的对象将被丢弃，并作为垃圾回收）。这乍一看可能觉得效率不高，但保证了正确的初始化。

静态初始化只有在必要时刻才会进行。初始化的顺序先是静态对象（如果它们之前没有被初始化的话），然后是非静态对象。静态初始化只会在首次加载 Class 对象时初始化一次。

第七章

private

关键字 private 意味着除了包含该成员的类，其他任何类都无法访问这个成员。同一包中的其他类无法访问 private 成员，因此这等于说是自己隔离自己。另一方面，让许多人合作创建一个包也是有可能的。使用 private，你可以自由地修改那个被修饰的成员，无需担心会影响同一包下的其他类。

默认的包访问权限通常提供了足够的隐藏措施；记住，使用类的客户端程序员无法访问包访问权限成员。这样做很好，因为默认访问权限是一种我们常用的权限（同时也是一种在忘记添加任何访问权限时自动得到的权限）。因此，通常考虑的是把哪些成员声明成 public 供客户端程序员使用。所以，最初不常使用关键字 private，因为程序没有它也可以照常工作。然而，使用 private 是非常重要的，尤其是在多线程环境中。

不能因为类中某个对象的引用是 private，就认为其他对象也无法拥有该对象的 public 引用。