自从有了编程语言就有了goto，实际上，在汇编语言时代，goto是程序流程控制的雏形：如果条件A，则跳转到这里，否则跳转到那里。编译器最终生成的都是汇编代码。所以如果你读过这种代码的话，你会看到程序里充斥这跳转，Java编译器会产生它自己的汇编代码，但是这种代码是在Java虚拟机上运行而不是直接在cpu硬件上运行。

Goto则是源代码级别上的跳转，而这才是给它带来坏名声的真正原因。如果程序总是从这里跳到那里，那么是不是有什么办法能重新整理代码让它不要那么跳呢？其实碰到这种情况，中庸之道才是最可取。问题不在于用没用goto，而在于是不是滥用了goto；在一些极为特殊的情况下，实际上goto是最好的流程控制语句。

如果有两个类型相同的对象，a和b，你可能会想知道该如何调用这两个对象的方法。如果只有一个方法，那么它又该怎样判断是对象a还是对象b在调用它呢？为了能让你用发消息给对象，这种简洁的，面向对象的语法来编写程序，编译器暗中做了许多事情。你所操控的那个对象的reference会被当作一个非常重要的参数传给方法。

假设你想在方法里使用当前的对象的reference，由于这个reference是由编译器秘密传递的，因此它没有标识符。为此Java加了一个关键词：this。This关键词只能用于方法内部，它负责返回调用这个方法的对象的reference。你可以把this对象的reference当作任何对象的reference。记住，如果你想在别的类的方法里调这个类的方法，那么无须使用this，直接调用就是了。当前对象的this会自动地用于其他方法。

Java类库可以通过提供一种被称为构造函数的特殊方法，来保证每个对象都能得到初始化。如果类有构造函数，那么Java就会在对象刚刚创建，用户还来不及得到的时候，自动调用那个构造函数。默认的构造函数（也就是无参数的构造函数）是一种用于创建基本对象的无参数的构造函数。如果你写了一个没有构造函数的类，哪呢编译器会自动为你创建一个默认的构造函数。

尽管没有明确定义过，但是它调用了那个默认的构造函数，并且创建了一个新的对象。没有它，我们构建对象的时候就没方法可调。但是，只要定义了构造函数（不管带不带参数），编译器就不会再自动合成默认的构造函数了。

要理解垃圾回收器是如何工作的，你就得先了解各种设计方案的原理。Reference counting是一种简单的，但却比较慢的方案。它的意思是，每个对象都要包含一个reference计数器，每次有reference连接到这个对象的时候，这个计数器就会做递增。每次有reference离开作用域，或者是设成null的时候这个计数器就会做递减。这样，管理reference计数器就成了程序运行期间的一项不大，但却无法摆脱的负担了。垃圾回收器扫描一遍所有的对象，找到reference计数器为零的对象，释放其内存。但是这种方案有个缺点，那就是如果一堆垃圾对象相互引用并且连成一个环的话，那它们的reference计数器就不会是零了。要让垃圾回收器找出这种自我引用的对象，需要花更多的力气。Reference计数通常被用于解释垃圾回收的技术，但是似乎没有哪种JVM采纳了这种设计。

有时你需要重新抛出那个刚捕捉到的，用Exception捕捉到的异常。由于你已经有了当前异常的reference，因此你可以直接讲那个reference重抛出来。重抛会把异常送到更高一层的异常处理程序去。同一个try区块的其它catch子句都将被忽略。此外，它还会保留异常对象里的所有信息，这样捕获这个异常的上一层的异常处理程序就能够提取这个对象中的所有信息了。

如果你直接重抛当前的异常，则printStackTrace()方法所打印出来的那些保存在异常对象里的信息，还会指向异常发生的地方，它们不会被指到你重抛异常的地点。如果你要装载新的栈轨迹信息，你可以调用fillInStackTrace()，这个方法会将当前栈的信息塞进旧的异常对象中，并返回一个throwable对象。

如果方法抛出了异常，那么必须要有能捕捉这个异常，并且处理这个异常的程序。异常处理有一个好处，就是它能让你集中精力在一个地方解决问题，然后将处理错误的代码分开来放在另一个地方。要想理解异常是怎样被捕捉到的，你必须首先懂得“守护区域”的概念。这是一段可能会产生异常的代码，并且后面还跟着要处理这些异常的代码。

如果你从方法里面抛出了一个异常（或是在这个方法调用的另一个方法里面抛出一个异常），那么抛出异常的同时，这个方法会退出运行。如果你不想被throw出方法，那么你可以在这个方法的内部建一个特殊的区块来捕获这个异常。这就被称为try区块，因为你在这里try各种方法调用。Try区块是跟在try关键词后面的程序块。

Static关键字是在类中描述成员属性和成员方法是静态的；静态的成员好处在哪里呢？例如我们声明了person的人类，在person这个类里如果我们加上一个“人所属国家”的属性，这样用person这个类实例化出几百个或者更多实例对象，每个对象里面就都有“所属国家”的属性了，如果开发的项目就是为中国人而开发的，那么每个对象里面就都有一个国家的属性是“中国”其它的属性是不同的。

如果我们把“国家”的属性做成静态的成员，这样国家的属性在内存中就只有一个，而让这几百个或更多的对象公用这一个属性，static成员能够限制外部的访问，因为static的成员是属于类的，是不属于任何对象实例，是在类第一次被加载的时候分配的空间，其他类是无法访问的，只对类的实例共享，能一定程度对类该成员形成保护。

PHP与大多数面向对象编程语言一样，不支持多重继承，也就是说每个类只能继承一个父类。为了解决这个问题，PHP引入了接口，接口的思想是指定了一个实现了该接口的类必须实现的一系列方法。接口是一种特殊的抽象类，抽象类又是一种特殊的类，所以接口也是一种特殊的类，为什么说接口是一种特殊的抽象类呢？如果一个抽象类里面的所有的方法都是抽象方法，那么我们就换一种声明方法使用接口；也就是说接口里面所有的方法必须都是声明为抽象方法，另外接口里面不能声明变量，而且接口里面所有的成员都是public权限的。所以子类在实现的时候也一定要使用public权限实现。

PHP主要以三种方式来进行扩展：外部模块，内建模块和Zend引擎。外部模块可以在脚本运行时使用dl函数载入。这个函数从磁盘载入一个共享对象并将它的功能与调用该函数的脚本进行绑定并使之生效。脚本终止后，这个外部模块将在内存中被丢弃。这种方式有利有弊。

优点是：外部模块不需要重新对PHP进行编译。PHP通过外包方式来让自身的体积保持很小；缺点是：共享对象在每次脚本调用时都需要对其进行加载，速度较慢。附加的外部模块文件会让磁盘变得比较散乱。每个想使用该模块功能的脚本都必须使用dl函数手动加载，或者在PHP.INI文件中添加一些扩展标签（这并不总是一个恰当的解决方案）。

Zend是用一些特定的规范构建的。几乎对于每一项重要的任务，Zend都预先提供了即为方便的宏。这些宏定义大多可以在Zend.h和Zend_API.h中找到。资源管理仍然是一个极为关键的问题，尤其是对服务器软件而言。资源里最具宝贵的则非内存莫属了，内存管理也必须极端小心。内存管理在Zend中已经被部分抽象，而且你也应该坚持使用这些抽象，原因显而易见：由于得以抽象，Zend就可以完全控制内存的分配。Zend可以确定一块内存是否在使用，也可以自动释放未使用和失去引用的内存块，因此就可以避免内存泄漏。