异常处理

在程序运行时，异常让你可以平滑的处理意外状况。为了演示JVM处理异常的方式，考虑NitPickyMath类，它提供对整数进行加，减，乘，除以及取余的操作。

NitPickyMath提供的这些操作和Java语言的“+”，“-”，“*”，“/”和“%”是一样的，除了NitPickyMath中的方法在以下情况下会抛出检查型（checked）异常：上溢出，下溢出以及被0除。0做除数时，JVM会抛出ArithmeticException异常，但是上溢出和下溢出不会引发任何异常。NitPickyMath中抛出异常的方法定义如下：

NitPickyMath类中的remainder()方法就是一个抛出和捕获异常的简单方法。

remainder()方法，只是简单的对当作参数传递进来的2个整数进行取余操作。如果取余操作的除数是0，会引发ArithmeticException异常。remainder()方法捕获这个异常，并重新抛出DivideByZeroException异常。

DivideByZeroException和ArithmeticException的区别是，DivideByZeroException是检查型（checked）异常，而ArithmeticException是非检查（unchecked）型异常。由于ArithmeticException是非检查型异常，一个方法就算会抛出该异常，也不必在其throw子句中声明它。任何Error或RuntimeException异常的子类异常都是非检查型异常。（ArithmeticException就是RuntimeException的子类。）通过捕获ArithmeticException和抛出DivideByZeroException，remainder()方法强迫它的调用者去处理除数为0的可能性，要么捕获它，要么在其throw子句中声明DivideByZeroException异常。这是因为，像DivideByZeroException这种在方法中抛出的检查型异常，要么在方法中捕获，要么在其throw子句中声明，二者必选其一。而像ArithmeticException这种非检查型异常，就不需要去显式捕获和声明。

javac为remainder()方法生成的字节码序列如下：

remainder()方法的字节码有2个单独的部分。第一部分是该方法的正常执行路径，这部分从第0行开始，到第3行结束。第二部分是从第4行开始，到12行结束的catch子句。

主字节码序列中的irem指令可能会抛出ArithmeticException异常。如果异常发生了，JVM通过在异常表中查找匹配的异常，它会知道要跳转到相应的异常处理的catch子句的字节码序列部分。每个捕获异常的方法，都跟类文件中与方法字节码一起交付的异常表关联。每一个捕获异常的try块，都是异常表中的一行。每行4条信息：开始行号（from）和结束行号（to），要跳转的字节码序列行号（target），被捕获的异常类的常量池索引（type）。remainder()方法的异常表如下所示：

上面的异常表表明，行号1到3范围内，ArithmeticException将被捕获。异常表中的“to”下面的结束行号始终比异常捕获的最大行号大1，上表中，结束行号为4，而异常捕获的最大行号是3。行号0到3的字节码序列对应remainder()方法中的try块。“target”列中，是行0到3的字节码发生ArithmeticException异常时要跳转到的目标行号。

如果方法执行过程中产生了异常，JVM会在异常表中查找匹配行。异常表中的匹配行要符合下面的条件：当前pc寄存器的值要在该行的表示范围之内，[from, to)，且产生的异常是该行所指定的异常类或其子类。JVM按从上到下的次序查找异常表。当找到了第一个匹配行，JVM把pc寄存器设为新的跳转行号，从此行继续往下执行。如果找不到匹配行，JVM弹出当前栈帧，并重新抛出同一个异常。当JVM弹出当前栈帧时，它会终止当前方法的执行，返回到调用该方法的上一个方法那里。这时，在上一个方法里，并不会继续正常的执行过程，而是抛出同样的异常，促使JVM重新查找该方法的异常表。

Java程序员可以用throw语句抛出像remainder()方法的catch子句中的异常，DivideByZeroException。下表列出了抛出异常的字节码：

athrow指令把栈顶元素弹出，该元素必须是Throwable的子类或其自身的对象引用，而抛出的异常类型由栈顶弹出的对象引用所指明。

本文译自：How the Java virtual machine handles exceptions

什么是JVM？为什么要有它？

JVM（Java虚拟机）是一个运行已编译Java程序的抽象计算机。之所以说是”虚拟“的，是因为它基于“真正”的硬件平台和操作系统，一般以软件的形式实现。所有的Java程序都为JVM而编译。因此，在特定平台上运行已编译Java程序之前，该平台的JVM必须先要被实现。

JVM在Java的跨平台特性中，起着中间人的角色。它在已编译Java程序与底层硬件平台和操作系统之间，提供一个抽象层。JVM对Java的可移植性非常关键，因为，已编译Java程序运行在JVM之上，并独立于底层JVM的具体实现。

那么，是什么导致JVM的短小精悍？当被实现成软件时，JMV很小巧。它被设计成这样，是为了让它能够适用于尽可能多的地方，比如机顶盒，手机和个人电脑。JVM很精悍，是因为它的野心。”无处不在！“是它的战斗口号。它想要无处不在，并且Java程序”一次编写，到处运行“的程度说明了它的成功。

Java字节码

Java程序被编译成一种叫做字节码的东东。JVM执行Java字节码，所以字节码可以被认为是JVM的机器语言。Java编译器读取Java源文件，把它翻译成Java字节码并保存到类文件（.class文件）中。编译器会为源码中的每一个类生成一个类文件。

对JVM来说，字节码流就是指令序列。每条指令包含一个单字节的操作码和零个或多个操作数。操作码告诉JVM要执行的操作。如果JVM需要除操作码之外更多的信息去执行一项操作，那么，需要的信息作为操作数，紧跟在操作码之后。

每个字节码都有一个助记符，它可被当作JVM的汇编语言。例如，有个指令会让JVM把0压到堆栈中。该指令的助记符是iconst_0，字节码值是0×60。该指令没有操作数。另一个指令让程序的执行在内存中无条件向前向后跳转。这个指令需要一个操作数，它是一个指明从当前内存地址开始的2字节无符号偏移量。通过把偏移量加到当前内存地址，JVM可以获得要跳转的目标内存地址。该指令的助记符是goto，它的字节码值是0xa7。

虚拟部分

JVM的“虚拟硬件”可以分为四个部分：寄存器组，栈区，垃圾收集堆和方法区。这些部分很抽象，就像由它们组成的虚拟机一样；但是它们必须在每个JVM的实现中，以某种形式存在。

JVM中地址的是32位（4字节）的，因此，JVM可以处理4GB（2的32次方）的内存。栈区，垃圾收集堆和方法区处在这4GB内存中的某个地方，至于它们的具体内存地址，这取决于每个特定JVM的实现者。

JVM中一个字（word）的长度是32位的。JVM中有少数几个原始数据类型：byte（8位），short（16位），int（32位），long（64位），float（32位），double（64位），char（16位）。除了无符号Unicode字符char之外，其他6种数字类型都是有符号的。这些类型可以方便的映射到Java程序员可用的数据类型。另一个原始类型是对象句柄，它是一个指向堆中对象的32位地址。

由于包含字节码，方法区以字节边界对齐。栈和垃圾收集堆以字（32位）边界对齐1。

寄存器：我少我自豪

JVM有1个程序计数器（counter）和3个管理栈的寄存器（register）。它只有很少的寄存器，是因为JVM字节码指令主要操作栈区。这种面向栈的设计，使得JVM指令集和JVM实现很小巧。

JVM使用程序计数器（也叫pc寄存器），跟踪当前执行指令的内存位置。另外3个寄存器（optop寄存器，frame寄存器和vars寄存器）指向当前执行方法栈帧上不同的部位。执行方法的栈帧持有特定方法调用的状态（本地变量，即时计算结果等）。

方法区和程序计数器

方法区是字节码呆的地方。程序计数器跟踪执行线程。当前字节码指令执行后，程序计数器会包含下一条执行指令的地址：一条指令执行之后，JVM把程序计数器设置为紧跟上一条指令的指令地址，除非上一条指令具体指明一次跳转。

Java栈和相关寄存器

Java栈用来保存字节码指令的参数和执行结果，给方法传递参数和返回结果，保存每个方法调用的状态。方法调用的状态被称为调用栈帧。var寄存器，frame寄存器和optop寄存器指向当前栈帧的不同部位。

Java栈帧有3个区：本地变量，执行环境和操作数栈。本地变量区，包含当前方法调用中使用的所有本地变量。它由vars寄存器指向。执行环境区用来维护栈区本身的操作。它被frame寄存器指向。操作数区用来作为字码指令的工作区。正是在这里，存放着字节码指令的参数和其返回结果。操作数栈区的顶部被optop寄存器指向。

执行环境通常夹在本地变量和操作数栈中间。当前执行方法的操作数栈总是在栈区的最上面，所以optop寄存器总是指向整个Java栈的顶部。

垃圾收集堆

堆是Java对象生存的地方。任何时候，你用new操作符分配的内存，都来自堆中。Java语言不允许你直接释放分配的内存。运行时环境会跟踪堆上每个对象的引用，自动释放那些不被引用的对象所占据的内存，这个过程被称为垃圾收集。

参考

1. 关于内存对齐方式，请参考Data alignment: Straighten up and fly right。

本文译自：The lean, mean, virtual machine

原创文章，转载请注明： 转载自LetsCoding.cn
本文链接地址: 短小精悍的虚拟机：JVM基本结构和功能介绍

策略模式通过封装一组相关算法，为Client提供运行时的灵活性。Client可以在运行时，选择任一算法，而不改变使用算法的Context。一些流行的策略模式的例子是写那些使用算法的代码，例如加密算法、压缩算法、排序算法。另一方面，状态模式允许对象，在不同的状态拥有不同的行为。因为现实世界中的对象通常都是有状态的，所以它们在不同状态，行为也不一样。例如，VM（自动售货机）只在hasCoin状态才给你吐商品；你不投币，它是不会吐的。现在你可以清楚的看出它们的不同之处了：它们的意图是不同的。状态模式帮助对象管理状态，而策略模式允许Client选择不同的行为。

另一个不那么容易能看出来的区别是：是谁促使了行为的改变。策略模式中，是Client提供了不同的策略给Context；状态模式中，状态转移由Context或State自己管理。另外，如果你在State中管理状态转移，那么它必须持有Context的引用。例如，在VM的例子中，State对象需要调用VM的setState()方法去改变它的状态。另一方面，Strategy从不持有Context的引用，是Client把所选择的Strategy传递给Context。由于状态模式和策略模式的区别，是流行的Java设计原则类面试题之一，我们将会在本文探讨在Java中，状态模式和策略模式的异同，这可以加深你对它们的理解。

相似之处

如果你看看状态模式和策略模式的UML图，就会发现它们的结构非常相似。使用State对象改变自己行为的对象被称为Context对象；相似的，使用Strategy对象改变自己行为的对象叫Context对象。记住，Client和Context打交道。在状态模式中，Context把方法调用委托给当前的状态对象，而在策略模式中，Context使用的Strategy对象，是被当做参数传递过来的，或在Context对象被创建时就被提供的。

这是专为经典的VM问题而设计的状态模式UML类图。你可以看出，VM的状态是个接口，它有表示不同状态的具体实现。每一个状态都持有Context的引用，用它来管理由Context触发的行为导致的状态转移。

这是专为实现排序功能而设计的策略模式UML类图。因为存在很多排序算法，该模式让Client在排序时选择适当的算法。事实上，Java的集合框架就使用这个模式，实现了用来排序的Collections.sort()方法。不同的是，它不允许Client选择排序算法，而是让它传递Comparator或Comparable接口的实例来指定比较策略。

让我们来看看它们之间更多的相似之处：

1. 添加新的状态或策略都很容易，而且不需要修改使用它们的Context对象。
2. 它们都让你的代码符合OCP原则。在状态模式和策略模式中，Context对象对修改是关闭的，添加新的状态或策略，都不需要修改Context。
3. 正如状态模式中的Context会有初始状态一样，策略模式同样有默认策略。
4. 状态模式以不同的状态封装不同的行为，而策略模式以不同的策略封装不同的行为。
5. 它们都依赖子类去实现相关行为。

不同之处

现在我们知道，状态模式和策略模式的结构是相似的，但它们的意图不同。让我们重温一下它们的主要不同之处：

1. 策略模式封装了一组相关算法，它允许Client在运行时使用可互换的行为；状态模式帮助一个类在不同的状态显示不同的行为。
2. 状态模式封装了对象的状态，而策略模式封装算法或策略。因为状态是跟对象密切相关的，它不能被重用；而通过从Context中分离出策略或算法，我们可以重用它们。
3. 在状态模式中，每个状态通过持有Context的引用，来实现状态转移；但是每个策略都不持有Context的引用，它们只是被Context使用。
4. 策略实现可以作为参数传递给使用它的对象，例如Collections.sort()，它的参数包含一个Comparator策略。另一方面，状态是Context对象自己的一部分，随着时间的推移，Context对象从一个状态转移到另一个状态。
5. 虽然它们都符合OCP原则，策略模式也符合SRP原则（单一职责原则），因为每个策略都封装自己的算法，且不依赖其他策略。一个策略的改变，并不会导致其他策略的变化。
6. 另一个理论上的不同：策略模式定义了对象“怎么做”的部分。例如，排序对象怎么对数据排序。状态模式定义了对象“是什么”和“什么时候做”的部分。例如，对象处于什么状态，什么时候处在某个特定的状态。
7. 状态模式中很好的定义了状态转移的次序；而策略模式并无此需要：Client可以自由的选择任何策略。
8. 一些常见的策略模式的例子是封装算法，例如排序算法，加密算法或者压缩算法。如果你看到你的代码需要使用不同类型的相关算法，那么考虑使用策略模式吧。而识别何时使用状态模式是很简单的：如果你需要管理状态和状态转移，但不想使用大量嵌套的条件语句，那么就是它了。
9. 最后但最重要的一个不同之处是，策略的改变由Client完成；而状态的改变，由Context或状态自己。

本文译自：Difference between State and Strategy Design Pattern in Java

原创文章，转载请注明： 转载自LetsCoding.cn
本文链接地址: Java中，状态模式和策略模式的区别