为什么 wait，notify 和 notifyAll 是在 Object 类中定义的而不是在 Thread 类中定义？

wait 和 notify 不仅仅是普通方法或同步工具，更重要的是它们是 Java 中两个线程之间的通信机制。对语言设计者而言, 如果不能通过 Java 关键字(例如 synchronized)实现通信此机制，同时又要确保这个机制对每个对象可用, 那么 Object 类则是的合理的声明位置。记住同步和等待通知是两个不同的领域，不要把它们看成是相同的或相关的。同步是提供互斥并确保 Java 类的线程安全，而 wait 和 notify 是两个线程之间的通信机制。
wait和notify的本质是基于条件对象的，而且只能由已经获得锁的线程调用。每个对象都可上锁，这是在 Object 类而不是 Thread 类中声明 wait 和 notify的另一个原因。java的每个Object都有一个隐式锁，这个隐式锁关联一个Condition条件对象，线程拿到这个隐式锁（比如进入synchronized代码区域），就可以调用wait，语义是在Condition条件对象上等待，其他的线程可以在这个Condition条件对象上等待，等满足条件之后，就可以调用notify或者notifyAll来唤醒所有在此条件对象上等待的线程。
在 Java 中，为了进入代码的临界区，线程需要锁定并等待锁，他们不知道哪些线程持有锁，而只是知道锁被某个线程持有，并且需要等待以取得锁, 而不是去了解哪个线程在同步块内，并请求它们释放锁。
Java 是基于 Hoare 的监视器的思想。在Java中，所有对象都有一个监视器。

线程在监视器上等待，为执行等待，我们需要2个参数：

一个线程
一个监视器(任何对象)

在 Java 设计中，线程不能被指定，它总是运行当前代码的线程。但是，我们可以指定监视器(这是我们称之为等待的对象)。这是一个很好的设计，因为如果我们可以让任何其他线程在所需的监视器上等待，这将导致“入侵”，影响线程执行顺序，导致在设计并发程序时会遇到困难。请记住，在 Java 中，所有在另一个线程的执行中造成入侵的操作都被弃用了(例如 Thread.stop 方法)。

第一个原因是围绕钻石.形继承问题产生的歧义，考虑一个类 A 有 foo() 方法, 然后 B 和 C 派生自 A, 并且有自己的 foo() 实现，现在 D 类使用多个继承派生自 B 和C，如果我们只引用 foo(), 编译器将无法决定它应该调用哪个 foo()。这也称为 Diamond 问题，因为这个继承方案的结构类似于菱形，见下图:
```
         A foo()    
        / \    
      /     \    
 foo() B     C foo()    
      \     /    
        \ /    
        D  foo()
```

即使我们删除钻石的顶部 A 类并允许多重继承，我们也将看到这个问题含糊性的一面。如果你把这个理由告诉面试官，他会问为什么 C++ 可以支持多重继承而 Java不行。嗯，在这种情况下，我会试着向他解释我下面给出的第二个原因，它不是因为技术难度, 而是更多的可维护和更清晰的设计是驱动因素,虽然这只能由Java言语设计师确认，我们只是推测。维基百科链接有一些很好的解释，说明在使用多重继承时，由于钻石问题，不同的语言地址问题是如何产生的。

多重继承确实使设计复杂化并在强制转换、构造函数链接等过程中产生问题。假设你需要多重继承的情况并不多，简单起见，明智的决定是省略它。此外，Java 可以通过使用接口支持单继承来避免这种歧义。由于接口只有方法声明而且没有提供任何实现，因此只有一个特定方法的实现，因此不会有任何歧义。

为什么Java不支持运算符重载？

另一个类似的 Java 面试难题。为什么 C++ 支持运算符重载而 Java 不支持? 有人可能会说 + 运算符在 Java 中已被重载用于字符串连接，不要被这些论据所欺骗。字符串相加实际是调用方法append方法。比如：

String x = "a1" + "a2"
其实在编译后，代码变为
String x = (new StringBuilder(String.valueOf("a1"))).append("a2").toString();
这就是为什么在操作String时建议采用StringBuffer了，上面的操作显然对多次String的相加不利。

为什么 Java 不支持运算符重载。

简单性和清晰性。清晰性是Java设计者的目标之一。设计者不是只想复制语言，而是希望拥有一种清晰，真正面向对象的语言。添加运算符重载比没有它肯定会使设计更复杂，并且它可能导致更复杂的编译器, 或减慢 JVM，因为它需要做额外的工作来识别运算符的实际含义，并减少优化的机会, 以保证 Java 中运算符的行为。
避免编程错误。Java 不允许用户定义的运算符重载，因为如果允许程序员进行运算符重载，将为同一运算符赋予多种含义，这将使任何开发人员的学习曲线变得陡峭，事情变得更加混乱。据观察，当语言支持运算符重载时，编程错误会增加，从而增加了开发和交付时间。由于 Java 和 JVM 已经承担了大多数开发人员的责任，如在通过提供垃圾收集器进行内存管理时，因为这个功能增加污染代码的机会, 成为编程错误之源, 因此没有多大意义。
JVM复杂性。从JVM的角度来看，支持运算符重载使问题变得更加困难。通过更直观，更干净的方式使用方法重载也能实现同样的事情，因此不支持 Java 中的运算符重载是有意义的。与相对简单的 JVM 相比，复杂的 JVM 可能导致 JVM 更慢，并为保证在 Java 中运算符行为的确定性从而减少了优化代码的机会。
让开发工具处理更容易。这是在Java中不支持运算符重载的另一个好处。省略运算符重载后使语言更容易处理，如静态分析等，这反过来又更容易开发处理语言的工具，例如 IDE 或重构工具。Java 中的重构工具远胜于 C++。

为什么 String 在 Java 中是不可变的？

字符串是我们Java程序使用得最多的一种数据类型,所以JVM为我们提供了字符串缓存池.所以String对象缓存在String池中。由于缓存的字符串在多个客户之间共享，如果字符串为可变的就会存在风险，其中一个客户的操作会影响所有其他客户。例如，如果一段代码将String“Test”的值更改为“TEST”，则所有其他客户也将看到该值。由于 String 对象的缓存是性能的重要保证，因此通过使 String 类不可变来避免这种风险。
String 是 final 的，因此没有人可以通过扩展和覆盖行为来破坏 String 类的不变性、缓存、散列值的计算等。
String 类不可变的另一个原因可能是由于 HashMap。由于把字符串作为 HashMap 键很受欢迎。对于键值来说，不可变性是非常的重要，以便用它们检索存储在 HashMap 中的值对象。由于 HashMap 的工作原理是散列，因此需要具有相同的值才能正常运行。如果在插入后修改了 String 的内容，可变的 String 将在插入和检索时生成两个不同的哈希码，可能会丢失 Map 中的值对象。
字符串已被广泛用作许多 Java 类的参数，例如，为了打开网络连接，你可以将主机名和端口号作为字符串传递，你可以将数据库 URL 作为字符串传递, 以打开数据库连接，你可以通过将文件名作为参数传递给 File I/O 类来打开 Java 中的任何文件。如果 String 不是不可变的，这将导致严重的安全威胁，我的意思是有人可以访问他有权授权的任何文件，然后可以故意或意外地更改文件名并获得对该文件的访问权限。由于不变性，你无需担心这种威胁。这个原因也说明了，为什么 String 在 Java 中是最终的，通过使 java.lang.String final，Java设计者确保没有人覆盖 String 类的任何行为。
由于 String 是不可变的，它可以安全地共享许多线程，这对于多线程编程非常重要. 并且避免了 Java 中的同步问题，不变性也使得String 实例在 Java 中是线程安全的，这意味着你不需要从外部同步 String 操作。关于 String 的另一个要点是由截取字符串 SubString 引起的内存泄漏，这不是与线程相关的问题，但也是需要注意的。
为什么 String 在 Java 中是不可变的另一个原因是允许 String 缓存其哈希码，Java 中的不可变 String 缓存其哈希码，并且不会在每次调用 String 的 hashcode 方法时重新计算，这使得它在 Java 中的 HashMap 中使用的 HashMap 键非常快。简而言之，因为 String 是不可变的，所以没有人可以在创建后更改其内容，这保证了 String 的 hashCode 在多次调用时是相同的。
String 不可变的绝对最重要的原因是它被类加载机制使用，因此具有深刻和基本的安全考虑。如果 String 是可变的，加载“java.io.Writer” 的请求可能已被更改为加载 “mil.vogoon.DiskErasingWriter”. 安全性和字符串池是使字符串不可变的主要原因

为什么 char 数组比 Java 中的 String 更适合存储密码？

由于字符串在 Java 中是不可变的，如果你将密码存储为纯文本，它将在内存中可用，直到垃圾收集器清除它. 并且为了可重用性，会存在 String 在字符串池中, 它很可能会保留在内存中持续很长时间，从而构成安全威胁。
由于任何有权访问内存转储的人都可以以明文形式找到密码，这是另一个原因，你应该始终使用加密密码而不是纯文本。由于字符串是不可变的，所以不能更改字符串的内容，因为任何更改都会产生新的字符串，而如果你使用char[]，你就可以将所有元素设置为空或零。因此，在字符数组中存储密码可以明显降低窃取密码的安全风险。
Java 本身建议使用 JPasswordField 的 getPassword() 方法，该方法返回一个 char[] 和不推荐使用的getTex() 方法，该方法以明文形式返回密码，由于安全原因。应遵循 Java 团队的建议, 坚持标准而不是反对它。
使用 String 时，总是存在在日志文件或控制台中打印纯文本的风险，但如果使用 Array，则不会打印数组的内容而是打印其内存位置。虽然不是一个真正的原因，但仍然有道理。
```
 String strPassword =“Unknown”; 
 char [] charPassword = new char [] {'U'，'n'，'k'，'w'，'o'，'n'}; 
 System.out.println(“字符密码：”+ strPassword);
 System.out.println(“字符密码：”+ charPassword);
```

输出

字符串密码：Unknown
字符密码：[C @110b053

我还建议使用散列或加密的密码而不是纯文本，并在验证完成后立即从内存中清除它。因此,在Java中,用字符数组用存储密码比字符串是更好的选择。虽然仅使用char[]还不够，还你需要擦除内容才能更安全。

如何使用双重检查锁定在 Java 中创建线程安全的单例？

使用volatile + 双重检查. volatile是会保证被修饰的变量的可见性(至于如何保证可见性请参考volatile介绍) 和有序性.volatile的有序性做一下简单的介绍,被volatile修饰的变量不参与指令重排,在操作volatile变量时在变量操作之前的代码一定是执行完毕并且是可见的, 在变量操作之后的代码一定是还没有被执行的。

如果你的Serializable类包含一个不可序列化的成员，会发生什么？你是如何解决的？

什么是 Java 序列化序列化是把对象改成可以存到磁盘或通过网络发送到其他运行中的 Java 虚拟机的二进制格式的过程, 并可以通过反序列化恢复对象状态. Java 序列化API给开发人员提供了一个标准机制, 通过 java.io.Serializable 和 java.io.Externalizable 接口, ObjectInputStream 及ObjectOutputStream 处理对象序列化. Java 程序员可自由选择基于类结构的标准序列化或是他们自定义的二进制格式, 通常认为后者才是最佳实践, 因为序列化的二进制文件格式成为类输出 API的一部分, 可能破坏 Java 中私有和包可见的属性的封装.
如何序列化让 Java 中的类可以序列化很简单. 你的 Java 类只需要实现 java.io.Serializable 接口, JVM 就会把 Object 对象按默认格式序列化。让一个类是可序列化的需要有意为之。类可序列会可能为是一个长期代价，可能会因此而限制你修改或改变其实现. 当你通过实现添加接口来更改类的结构时，添加或删除任何字段可能会破坏默认序列化，这可以通过自定义二进制格式使不兼容的可能性最小化, 但仍需要大量的努力来确保向后兼容性。序列化如何限制你更改类的能力的一个示例是SerialVersionUID。如果不显式声明 SerialVersionUID, 则 JVM 会根据类结构生成其结构，该结构依赖于类实现接口和可能更改的其他几个因素。假设你新版本的类文件实现的另一个接口,JVM将生成一个不同的SerialVersionUID的,当你尝试加载旧版本的程序序列化的旧对象时, 你将获得无效类异常 InvalidClassException。
什么是 serialVersionUID ？如果你不定义这个, 会发生什么？

serialVersionUID 是一个 private static final long 型 ID, 当它被印在对象上时, 它通常是对象的哈希码,你可以使用 serialver 这个 JDK 工具来查看序列化对象的 serialVersionUID。SerialVerionUID 用于对象的版本控制。也可以在类文件中指定 serialVersionUID。不指定 serialVersionUID的后果是,当你添加或修改类中的任何字段时, 则已序列化类将无法恢复, 因为为新类和旧序列化对象生成的 serialVersionUID 将有所不同。Java 序列化过程依赖于正确的序列化对象恢复状态的, ,并在序列化对象序列版本不匹配的情况下引发 java.io.InvalidClassException 无效类异常。

序列化时,你希望某些成员不要序列化？你如何实现它？

transient 变量，瞬态和静态变量会不会得到序列化等，所以,如果你不希望任何字段是对象的状态的一部分, 然后声明它静态或瞬态根据你的需要, 这样就不会是在 Java 序列化过程中被包含在内。

如果类中的一个成员未实现可序列化接口，会发生什么情况？

关于Java 序列化过程的一个简单问题。如果尝试序列化实现了可序列化接口的类的对象，但该对象包含对不可序列化类的引用，则在运行时将引发不可序列化异常 NotSerializableException，这就是为什么我始终将一个可序列化警报(在我的代码注释部分中)，作为代码注释最佳实践之一，提示开发人员记住这一事实，在可序列化类中添加新字段时要注意。

如果类是可序列化的, 但其超类不是, 则反序列化后从超级类继承的实例变量的状态如何？

Java 序列化过程仅在对象层级都是可序列化的类中继续，即：实现了可序列化接口，如果从超级类没有实现可序列化接口，则超级类继承的实例变量的值将通过调用构造函数初始化。且一旦构造函数链启动,就不可能停止，因此，即使层次结构中更高的类成员变量实现了可序列化接口，也将通过执行构造函数创建，而不再是反序列化得到。如你所见，这个序列化面试问题看起来非常不易回答，但如果你熟悉关键概念，则并不难。

是否可以自定义序列化过程, 或者是否可以覆盖 Java 中的默认序列化过程？

答案是肯定的, 可以。我们都知道,对于序列化一个对象需调用 ObjectOutputStream.writeObject(saveThisObject), 并用 ObjectInputStream.readObject() 读取对象, 但 Java 虚拟机为你提供的还有一件事, 是定义这两个方法。如果在类中定义这两种方法, 则 JVM 将调用这两种方法, 而不是应用默认序列化机制。你可以在此处通过执行任何类型的预处理或后处理任务来自定义对象序列化和反序列化的行为。需要注意的重要一点是要声明这些方法为私有方法, 以避免被继承、重写或重载。由于只有 Java 虚拟机可以调用类的私有方法, 你的类的完整性会得到保留, 并且 Java 序列化将正常工作。

假设新类的超级类实现可序列化接口, 如何避免新类被序列化？

这是在 Java 序列化中不好回答的问题。如果类的 Super 类已经在 Java 中实现了可序列化接口，那么它在 Java 中已经可以序列化，因为你不能取消接口，它不可能真正使它无法序列化类, 但是有一种方法可以避免新类序列化。为了避免 Java 序列化,你需要在类中实现 writeObject() 和 readObject() 方法, 并且需要从该方法引发不序列化异常NotSerializableException。这是自定义 Java 序列化过程的另一个好处, 如上述序列化面试问题中所述, 并且通常随着面试进度, 它作为后续问题提出。

在 Java 中的序列化和反序列化过程中使用哪些方法？

这是很常见的面试问题, 在序列化基本上面试官试图知道: 你是否熟悉 readObject() 的用法、writeObject()、readExternal() 和 writeExternal()。 Java 序列化由java.io.ObjectOutputStream类完成。该类是一个筛选器流, 它封装在较低级别的字节流中, 以处理序列化机制。要通过序列化机制存储任何对象, 我们调用 ObjectOutputStream.writeObject(savethisobject), 并反序列化该对象, 我们称之为 ObjectInputStream.readObject()方法。调用以 writeObject() 方法在 java 中触发序列化过程。关于 readObject() 方法, 需要注意的一点很重要一点是, 它用于从持久性读取字节, 并从这些字节创建对象, 并返回一个对象, 该对象需要类型强制转换为正确的类型。

假设你有一个类,它序列化并存储在持久性中，然后修改了该类以添加新字段。如果对已序列化的对象进行反序列化, 会发生什么情况？

这取决于类是否具有其自己的 serialVersionUID。正如我们从上面的问题知道, 如果我们不提供 serialVersionUID, 则 Java 编译器将生成它, 通常它等于对象的哈希代码。通过添加任何新字段, 有可能为该类新版本生成的新 serialVersionUID 与已序列化的对象不同, 在这种情况下, Java 序列化 API 将引发 java.io.InvalidClassException, 因此建议在代码中拥有自己的 serialVersionUID, 并确保在单个类中始终保持不变。

Java序列化机制中的兼容更改和不兼容更改是什么？

真正的挑战在于通过添加任何字段、方法或删除任何字段或方法来更改类结构, 方法是使用已序列化的对象。根据 Java 序列化规范, 添加任何字段或方法都面临兼容的更改和更改类层次结构或取消实现的可序列化接口, 有些接口在非兼容更改下。对于兼容和非兼容更改的完整列表, 我建议阅读 Java 序列化规范。

我们可以通过网络传输一个序列化的对象吗？

是的 ,你可以通过网络传输序列化对象, 因为 Java 序列化对象仍以字节的形式保留, 字节可以通过网络发送。你还可以将序列化对象存储在磁盘或数据库中作为 Blob。

在 Java 序列化期间,哪些变量未序列化？

这个问题问得不同, 但目的还是一样的, Java开发人员是否知道静态和瞬态变量的细节。由于静态变量属于类, 而不是对象, 因此它们不是对象状态的一部分, 因此在 Java 序列化过程中不会保存它们。由于 Java 序列化仅保留对象的状态,而不是对象本身。瞬态变量也不包含在 Java 序列化过程中, 并且不是对象的序列化状态的一部分。在提出这个问题之后,面试官会询问后续内容, 如果你不存储这些变量的值, 那么一旦对这些对象进行反序列化并重新创建这些变量, 这些变量的价值是多少？这是你们要考虑的。

为什么Java中 wait 方法需要在 synchronized 的方法中调用？

另一个有难度的 Java 问题，wait 和 notify。它们是在有 synchronized 标记的方法或 synchronized 块中调用的，因为 wait 和 nodify 需要监视对其调用的 Object。

大多数Java开发人员都知道对象类的 wait()，notify() 和 notifyAll() 方法必须在 Java 中的 synchronized 方法或 synchronized 块中调用, 但是我们想过多少次, 为什么在 Java 中 wait, notify 和 notifyAll 来自 synchronized 块或方法?

最近这个问题在Java面试中被问到我的一位朋友，他思索了一下，并回答说: 如果我们不从同步上下文中调用 wait() 或 notify() 方法，我们将在 Java 中收到 IllegalMonitorStateException。

他的回答从实际效果上是正确的，但面试官对这样的答案不会完全满意，并希望向他解释这个问题。面试结束后他和我讨论了这个问题，我认为他应该告诉面试官关于 Java 中 wait()和 notify()之间的竞态条件，如果我们不在同步方法或块中调用它们就可能存在。

让我们看看竞态条件如何在 Java 程序中产生。它也是流行的线程面试问题之一。

为什么要等待来自 Java中的 synchronized 方法的 wait方法为什么必须从 Java 中的 synchronized 块或方法调用？

我们主要使用 wait()，notify()或notifyAll()方法用于Java中的线程间通信。一个线程在检查条件后正在等待，例如，在经典的生产者 - 消费者问题中，如果缓冲区已满，则生产者线程等待，并且消费者线程通过使用元素在缓冲区中创建空间后通知生产者线程。调用notify() 或 notifyAll() 方法向单个或多个线程发出一个条件已更改的通知，并且一旦通知线程离开 synchronized 块，正在等待的所有线程开始获取正在等待的对象锁定，幸运的线程在重新获取锁之后从 wait() 方法返回并继续进行。

让我们将整个操作分成几步，以查看Java 中 wait() 和 notify() 方法之间的竞争条件的可能性，我们将使用Produce Consumer 线程示例更好地理解方案：

Producer 线程测试条件(缓冲区是是否已满)并确认是否需要等待(如果发现缓冲区已满则需要等待)。
Consumer 线程在使用缓冲区中的元素后，设置条件。
Consumer 线程调用 notify() 方法; 这是不会被听到的，因为 Producer 线程还没有等待。
Producer 线程调用 wait() 方法并进入等待状态。

因此，由于竞态条件，我们可能会丢失通知，如果我们使用缓冲区或只使用一个元素，生产线程将永远等待，你的程序将挂起。“在Java 同步中等待 notify 和 notifyAll 现在让我们考虑如何解决这个潜在的竞态条件？这个竞态条件通过使用 Java 提供的 synchronized 关键字和锁定来解决。为了调用 wait()，notify() 或 notifyAll()，必须获得对我们调用方法的对象的锁定。由于 Java 中的 wait() 方法在等待之前释放锁定并在从 wait() 返回之前重新获取锁定方法，我们必须使用这个锁来确保检查条件(缓冲区是否已满) 和设置条件 (从缓冲区获取元素) 是原子的，这可以通过使用 synchronized 方法或块来实现。

总结一下，我们用 Java 中的 synchronized 方法或 synchronized 块调用 Java 中的 wait()，notify() 或 notifyAll() 方法来避免：

Java 会抛出 IllegalMonitorStateException，如果我们不调用来自同步上下文的wait()，notify()或者notifyAll()方法。
Javac 中 wait 和 notify 方法之间的任何潜在竞争条件。

你能用Java覆盖静态方法吗？如果我在子类中创建相同的方法是编译时错误？

不，你不能在Java中覆盖静态方法，但在子类中声明一个完全相同的方法不是编译时错误，这称为隐藏在Java中的方法。

你不能覆盖Java中的静态方法，因为方法覆盖基于运行时的动态绑定，静态方法在编译时使用静态绑定进行绑定。虽然可以在子类中声明一个具有相同名称和方法签名的方法，看起来可以在Java中覆盖静态方法，但实际上这是方法隐藏。Java不会在运行时解析方法调用，并且根据用于调用静态方法的 Object 类型，将调用相应的方法。这意味着如果你使用父类的类型来调用静态方法，那么原始静态将从父类中调用，另一方面如果你使用子类的类型来调用静态方法，则会调用来自子类的方法。简而言之，你无法在Java中覆盖静态方法。如果你使用像Eclipse或Netbeans这样的Java IDE，它们将显示警告静态方法应该使用类名而不是使用对象来调用，因为静态方法不能在Java中重写。

/** *

Java program which demonstrate that we can not override static method in Java.
Had Static method can be overridden, with Super class type and sub class object

static method from sub class would be called in our example, which is not the case. */ public class CanWeOverrideStaticMethod {

public static void main(String args[]) {

 Screen scrn = new ColorScreen();

 //if we can  override static , this should call method from Child class
 scrn.show(); //IDE will show warning, static method should be called from classname

}

class Screen{ /* * public static method which can not be overridden in Java */ public static void show(){ System.out.printf("Static method from parent class"); } }

class ColorScreen extends Screen{ /* * static method of same name and method signature as existed in super * class, this is not method overriding instead this is called * method hiding in Java */ public static void show(){ System.err.println("Overridden static method in Child Class in Java"); } }

输出: Static method from parent class 此输出确认你无法覆盖 Java 中的静态方法，并且静态方法基于类型信息而不是基于 Object 进行绑定。如果要覆盖静态方法，则会调用子类或 ColorScreen 中的方法。这一切都在讨论中我们可以覆盖 Java 中的静态方法。我们已经确认没有，我们不能覆盖静态方法，我们只能在Java中隐藏静态方法。创建具有相同名称和方法签名的静态方法称为Java 隐藏方法。IDE 将显示警告："静态方法应该使用类名而不是使用对象来调用", 因为静态方法不能在 Java 中重写。

Java问题整理