Kennen Sie diese 10 schwierigen Java-Interviewfragen?

Dies ist meine Sammlung der 10 schwierigsten Java-Interviewfragen. Diese Fragen stammen hauptsächlich aus dem Kernbereich von Java und beziehen sich nicht auf Probleme im Zusammenhang mit Java EE. Sie kennen vielleicht die Antworten auf diese schwierigen Java-Fragen oder haben das Gefühl, dass sie Ihre Java-Kenntnisse nicht genug herausfordern, aber das sind Fragen, die in verschiedenen Java-Interviews leicht gestellt werden, und viele, darunter auch meine Freunde und Programmiererkollegen, finden es schwierig Antwort.

(Weitere Empfehlungen für Interviewfragen: Java-Interviewfragen und -antworten)

1 Warum werden Wartezeiten und Benachrichtigungen in der Object-Klasse anstelle von Thread deklariert?

Eine schwierige Java-Frage. Wie können Sie diese Frage beantworten, wenn die Programmiersprache Java nicht von Ihnen entwickelt wurde? Allgemeine Kenntnisse und umfassende Kenntnisse der Java-Programmierung helfen bei der Beantwortung dieser schwierigen Interviewfrage zu den wichtigsten Java-Aspekten.

Warum warten, benachrichtigen und benachrichtigenAlle werden in der Object-Klasse und nicht in der Thread-Klasse definiert

Dies ist eine berühmte Java-Interviewfrage, die von erfahrenen Java-Entwicklern mit 2 bis 4 Jahren Erfahrung gestellt werden kann.

Das Gute an dieser Frage ist, dass sie das Verständnis des Interviewers über den Wartebenachrichtigungsmechanismus widerspiegelt und ob sein Verständnis dieses Themas klar ist. Genau wie auf die Frage, warum Mehrfachvererbung in Java nicht unterstützt wird oder warum String in Java endgültig ist, kann es auch auf diese Frage mehrere Antworten geben.

Jeder kann einige Gründe nennen, warum Warte- und Benachrichtigungsmethoden in der Objektklasse definiert sind. Meiner Interviewerfahrung nach zu urteilen, sind Wait und Nofity für die meisten Java-Programmierer immer noch am verwirrendsten, insbesondere für Entwickler mit 2 bis 3 Jahren Erfahrung. Wenn sie aufgefordert werden, Wait und Notify zu verwenden, werden sie verwirrt sein. Wenn Sie also zu einem Java-Interview gehen, stellen Sie sicher, dass Sie die Warte- und Benachrichtigungsmechanismen gut verstehen und problemlos Code schreiben können, indem Sie warten und die Mechanismen der Benachrichtigung durch Producer-Consumer-Probleme oder die Implementierung von Blockierungswarteschlangen usw. verstehen.

Warum Wait und Notify von einem synchronisierten Block oder einer synchronisierten Methode aufgerufen werden müssen und welche Unterschiede zwischen Wait-, Sleep- und Yield-Methoden in Java bestehen, wird für Sie interessant zu lesen sein, falls Sie es noch nicht getan haben. Warum gehören Wait, Notify und NotifyAll zur Object-Klasse? Warum sollten sie nicht zur Thread-Klasse gehören? Wichtig: Sie sind der Kommunikationsmechanismus zwischen zwei Threads in Java.

2) Jedes Objekt ist sperrbar, was ein weiterer Grund ist, Warten und Benachrichtigen in der Objektklasse statt in der Thread-Klasse zu deklarieren.

3) Um in den kritischen Abschnitt des Codes in Java zu gelangen, müssen Threads gesperrt und auf die Sperre gewartet werden

4) Java basiert auf der Idee von Hoares Monitor.

Der Thread wartet auf dem Monitor. Um das Warten durchzuführen, benötigen wir zwei Parameter:

• einen Monitor (beliebiges Objekt)

• Im Java-Design können Threads nicht angegeben werden immer der Thread, der den aktuellen Code ausführt. Wir können jedoch einen Monitor angeben (diesen nennen wir das Warteobjekt). Dies ist ein gutes Design, denn wenn ein anderer Thread auf dem erforderlichen Monitor warten könnte, würde dies zu „Einbrüchen“ führen, die beim Entwerfen gleichzeitiger Programme Schwierigkeiten bereiten würden. Denken Sie daran, dass in Java alle Vorgänge, die die Ausführung eines anderen Threads beeinträchtigen, veraltet sind (z. B. die Stop-Methode).

Warum unterstützt Java keine Mehrfachvererbung? Sie können die folgenden zwei Punkte berücksichtigen:

1) Der erste Grund ist die Mehrdeutigkeit rund um das Diamanten-Vererbungsproblem. Betrachten Sie eine Klasse A mit einer foo()-Methode, dann leiten sich B und C von A ab und haben ihre eigene foo()-Implementierung, die jetzt von Klasse D verwendet wird Wenn wir bei der von B und C abgeleiteten Mehrfachvererbung nur auf foo() verweisen, kann der Compiler nicht entscheiden, welches foo() er aufrufen soll. Dies wird auch Diamantproblem genannt, da die Struktur dieses Vererbungsschemas einer Raute ähnelt, siehe Bild unten:

                A foo()    
               / \    
             /     \    
 foo() B     C foo()    
             \     /    
               \ /    
               D  foo()

Selbst wenn wir die oberste A-Klasse der Raute entfernen und Mehrfachvererbung zulassen, werden wir die mehrdeutige Seite sehen dieses Problems. Wenn Sie dem Interviewer diesen Grund nennen, wird er fragen, warum C++ Mehrfachvererbung unterstützen kann, Java jedoch nicht. Nun, in diesem Fall würde ich versuchen, ihm den zweiten Grund zu erklären, den ich unten anführe. Er liegt nicht an technischen Schwierigkeiten, sondern an einer besseren Wartbarkeit und einem klareren Design sind die treibenden Faktoren, obwohl dies nur von Java-Sprachdesignern bestätigt werden kann, von uns spekulieren nur. Der Wikipedia-Link enthält einige gute Erklärungen, wie das Problem unterschiedlicher Sprachadressen aufgrund des Diamantproblems bei Verwendung der Mehrfachvererbung entsteht.

2) Der zweite und für mich überzeugendere Grund ist, dass Mehrfachvererbung das Design verkompliziert und Probleme bei Konvertierungen, Konstruktorverkettungen usw. verursacht. Angenommen, es gibt nicht viele Situationen, in denen Sie eine Mehrfachvererbung benötigen, wäre es eine kluge Entscheidung, sie der Einfachheit halber wegzulassen. Darüber hinaus kann Java diese Mehrdeutigkeit vermeiden, indem es die Einzelvererbung mithilfe von Schnittstellen unterstützt. Da die Schnittstelle nur über Methodendeklarationen verfügt und keine Implementierung bereitstellt, gibt es nur eine Implementierung einer bestimmten Methode und es kann daher keine Mehrdeutigkeit geben. (Für eine praktische und detaillierte Sammlung von Java-Interviewfragen können Sie auf die „Interview-Fragensammlung“ im offiziellen Java Zhiyin-Konto antworten.)

3 Warum unterstützt Java keine Operatorüberladung?

Eine weitere ähnlich knifflige Java-Frage. Warum unterstützt C++ das Überladen von Operatoren, Java jedoch nicht? Einige mögen sagen, dass der +-Operator in Java für die Zeichenfolgenverkettung überladen ist. Lassen Sie sich von diesen Argumenten nicht täuschen.

Im Gegensatz zu C++ unterstützt Java keine Operatorüberladung. Java bietet Programmierern keine kostenlose Überladung von Standardarithmetikoperatoren wie +, -, * und / usw. Wenn Sie zuvor C++ verwendet haben, fehlen Java im Vergleich zu C++ viele Funktionen. Beispielsweise unterstützt Java keine Mehrfachvererbung, es gibt keine Zeiger in Java und es gibt keine Referenzübergabe in Java. Eine weitere ähnliche Frage betrifft die Java-Übergabe als Referenz, die hauptsächlich zeigt, ob Java Parameter als Wert oder Referenz übergibt. Obwohl ich den wahren Grund dafür nicht kenne, denke ich, dass an der folgenden Aussage etwas Wahres dran ist, warum Java das Überladen von Operatoren nicht unterstützt.

1) Einfachheit und Klarheit. Klarheit ist eines der Ziele von Java-Designern. Anstatt die Sprache einfach zu kopieren, wollten die Designer eine klare, wirklich objektorientierte Sprache haben. Durch das Hinzufügen einer Operatorüberladung wird das Design definitiv komplexer als ohne, und es kann zu einem komplexeren Compiler führen oder die JVM verlangsamen, weil zusätzliche Arbeit erforderlich ist, um zu identifizieren, was der Operator tatsächlich bedeutet, und die Möglichkeiten zur Optimierung auf „Garantiert“ reduziert werden Operatorverhalten in Java.

2) Vermeiden Sie Programmierfehler. Java erlaubt kein benutzerdefiniertes Überladen von Operatoren, denn wenn Programmierern erlaubt wird, Operatoren zu überladen, werden demselben Operator mehrere Bedeutungen zugewiesen, was die Lernkurve für jeden Entwickler steiler macht und die Dinge verwirrender macht. Es wurde beobachtet, dass Programmierfehler zunehmen, wenn eine Sprache eine Überlastung durch Bediener unterstützt, wodurch sich die Entwicklungs- und Bereitstellungszeit verlängert. Da Java und die JVM durch die Bereitstellung eines Garbage Collectors bereits den größten Teil der Verantwortung des Entwicklers bei der Speicherverwaltung übernehmen, macht dies wenig Sinn, da diese Funktion die Wahrscheinlichkeit erhöht, den Code zu verunreinigen und zu einer Quelle von Programmierfehlern zu werden.

3) JVM-Komplexität. Aus JVM-Sicht erschwert die Unterstützung der Operatorüberlastung das Problem. Dasselbe kann durch Methodenüberladung auf intuitivere und sauberere Weise erreicht werden. Daher ist es sinnvoll, die Operatorüberladung in Java nicht zu unterstützen. Eine komplexe JVM kann im Vergleich zu einer relativ einfachen JVM zu einer langsameren JVM führen und die Möglichkeit verringern, den Code zu optimieren, um ein deterministisches Operatorverhalten in Java sicherzustellen.

4) Erleichtern Sie die Handhabung der Entwicklungstools. Dies ist ein weiterer Vorteil, wenn in Java keine Operatorüberladung unterstützt wird. Das Weglassen der Operatorüberladung erleichtert die Arbeit mit der Sprache, was wiederum die Entwicklung von Tools für die Arbeit mit der Sprache, wie z. B. IDEs oder Refactoring-Tools, erleichtert. Refactoring-Tools sind in Java weitaus besser als in C++.

4. Warum ist String in Java unveränderlich?

Meine liebsten Java-Interviewfragen, knifflig, aber auch sehr nützlich. Einige Interviewer stellen auch oft die Frage, warum String in Java endgültig ist.

Strings sind in Java unveränderlich, da String-Objekte im String-Pool zwischengespeichert werden. Da zwischengespeicherte Zeichenfolgen von mehreren Kunden gemeinsam genutzt werden, besteht immer das Risiko, dass sich Aktionen eines Kunden auf alle anderen Kunden auswirken. Wenn beispielsweise ein Code den Wert der Zeichenfolge „Test“ in „TEST“ ändert, wird dieser Wert auch allen anderen Clients angezeigt. Da die Caching-Leistung von String-Objekten ein wichtiger Aspekt ist, vermeiden Sie dieses Risiko, indem Sie die String-Klasse unveränderlich machen.

同时，String 是 final 的，因此没有人可以通过扩展和覆盖行为来破坏 String 类的不变性、缓存、散列值的计算等。String 类不可变的另一个原因可能是由于 HashMap。

由于把字符串作为 HashMap 键很受欢迎。对于键值来说，重要的是它们是不可变的，以便用它们检索存储在 HashMap 中的值对象。由于 HashMap 的工作原理是散列，因此需要具有相同的值才能正常运行。如果在插入后修改了 String 的内容，可变的 String将在插入和检索时生成两个不同的哈希码，可能会丢失 Map 中的值对象。

如果你是印度板球迷，你可能能够与我的下一句话联系起来。字符串是Java的 VVS Laxman，即非常特殊的类。我还没有看到一个没有使用 String 编写的 Java 程序。这就是为什么对 String 的充分理解对于 Java 开发人员来说非常重要。

String 作为数据类型，传输对象和中间人角色的重要性和流行性也使这个问题在 Java 面试中很常见。

为什么 String 在 Java 中是不可变的是 Java 中最常被问到的字符串访问问题之一，它首先讨论了什么是 String，Java 中的 String 如何与 C 和 C++ 中的 String 不同，然后转向在Java中什么是不可变对象，不可变对象有什么好处，为什么要使用它们以及应该使用哪些场景。

这个问题有时也会问：“为什么 String 在 Java 中是 final 的”。在类似的说明中，如果你正在准备Java 面试，我建议你看看《Java程序员面试宝典(第4版) 》，这是高级和中级Java程序员的优秀资源。它包含来自所有重要 Java 主题的问题，包括多线程，集合，GC，JVM内部以及 Spring和 Hibernate 框架等。

正如我所说，这个问题可能有很多可能的答案，而 String 类的唯一设计者可以放心地回答它。我在 Joshua Bloch 的 Effective Java 书中期待一些线索，但他也没有提到它。我认为以下几点解释了为什么 String 类在 Java 中是不可变的或 final 的：

1)想象字符串池没有使字符串不可变，它根本不可能，因为在字符串池的情况下，一个字符串对象/文字，例如 “Test” 已被许多参考变量引用，因此如果其中任何一个更改了值，其他参数将自动受到影响，即假设

String A="Test";
String B="Test";

现在字符串 B 调用 "Test".toUpperCase(), 将同一个对象改为“TEST”，所以 A 也是 “TEST”，这不是期望的结果。

下图显示了如何在堆内存和字符串池中创建字符串。

2)字符串已被广泛用作许多 Java 类的参数，例如，为了打开网络连接，你可以将主机名和端口号作为字符串传递，你可以将数据库 URL 作为字符串传递, 以打开数据库连接，你可以通过将文件名作为参数传递给 File I/O 类来打开 Java 中的任何文件。如果 String 不是不可变的，这将导致严重的安全威胁，我的意思是有人可以访问他有权授权的任何文件，然后可以故意或意外地更改文件名并获得对该文件的访问权限。由于不变性，你无需担心这种威胁。这个原因也说明了，为什么 String 在 Java 中是最终的，通过使 java.lang.String final，Java设计者确保没有人覆盖 String 类的任何行为。

3)由于 String 是不可变的，它可以安全地共享许多线程，这对于多线程编程非常重要. 并且避免了 Java 中的同步问题，不变性也使得String 实例在 Java 中是线程安全的，这意味着你不需要从外部同步 String 操作。关于 String 的另一个要点是由截取字符串 SubString 引起的内存泄漏，这不是与线程相关的问题，但也是需要注意的。

4)为什么 String 在 Java 中是不可变的另一个原因是允许 String 缓存其哈希码，Java 中的不可变 String 缓存其哈希码，并且不会在每次调用 String 的 hashcode 方法时重新计算，这使得它在 Java 中的 HashMap 中使用的 HashMap 键非常快。简而言之，因为 String 是不可变的，所以没有人可以在创建后更改其内容，这保证了 String 的 hashCode 在多次调用时是相同的。

5)String 不可变的绝对最重要的原因是它被类加载机制使用，因此具有深刻和基本的安全考虑。如果 String 是可变的，加载“java.io.Writer” 的请求可能已被更改为加载 “mil.vogoon.DiskErasingWriter”. 安全性和字符串池是使字符串不可变的主要原因。顺便说一句，上面的理由很好回答另一个Java面试问题: “为什么String在Java中是最终的”。要想是不可变的，你必须是最终的，这样你的子类不会破坏不变性。你怎么看？

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

另一个基于 String 的棘手 Java 问题，相信我只有很少的 Java 程序员可以正确回答这个问题。这是一个真正艰难的核心Java面试问题，并且需要对 String 的扎实知识才能回答这个问题。

这是最近在 Java 面试中向我的一位朋友询问的问题。他正在接受技术主管职位的面试，并且有超过6年的经验。如果你还没有遇到过这种情况，那么字符数组和字符串可以用来存储文本数据，但是选择一个而不是另一个很难。但正如我的朋友所说，任何与 String 相关的问题都必须对字符串的特殊属性有一些线索，比如不变性，他用它来说服访提问的人。在这里，我们将探讨为什么你应该使用char[]存储密码而不是String的一些原因。

字符串：

1)由于字符串在 Java 中是不可变的，如果你将密码存储为纯文本，它将在内存中可用，直到垃圾收集器清除它. 并且为了可重用性，会存在 String 在字符串池中, 它很可能会保留在内存中持续很长时间，从而构成安全威胁。

由于任何有权访问内存转储的人都可以以明文形式找到密码，这是另一个原因，你应该始终使用加密密码而不是纯文本。由于字符串是不可变的，所以不能更改字符串的内容，因为任何更改都会产生新的字符串，而如果你使用char[]，你就可以将所有元素设置为空白或零。因此，在字符数组中存储密码可以明显降低窃取密码的安全风险。

2)Java 本身建议使用 JPasswordField 的 getPassword() 方法，该方法返回一个 char[] 和不推荐使用的getTex() 方法，该方法以明文形式返回密码，由于安全原因。应遵循 Java 团队的建议, 坚持标准而不是反对它。

3)使用 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面试题大全，可以在Java知音公众号回复“面试题聚合”）

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

这个 Java 问题也常被问: 什么是线程安全的单例，你怎么创建它。好吧，在Java 5之前的版本, 使用双重检查锁定创建单例 Singleton 时，如果多个线程试图同时创建 Singleton 实例，则可能有多个 Singleton 实例被创建。从 Java 5 开始，使用 Enum 创建线程安全的Singleton很容易。但如果面试官坚持双重检查锁定，那么你必须为他们编写代码。记得使用volatile变量。

为什么枚举单例在 Java 中更好

枚举单例是使用一个实例在 Java 中实现单例模式的新方法。虽然Java中的单例模式存在很长时间,但枚举单例是相对较新的概念,在引入Enum作为关键字和功能之后,从Java5开始在实践中。本文与之前关于 Singleton 的内容有些相关, 其中讨论了有关 Singleton 模式的面试中的常见问题, 以及 10 个 Java 枚举示例, 其中我们看到了如何通用枚举可以。这篇文章是关于为什么我们应该使用Eeame作为Java中的单例,它比传统的单例方法相比有什么好处等等。

Java 枚举和单例模式

Java 中的枚举单例模式是使用枚举在 Java 中实现单例模式。单例模式在 Java 中早有应用, 但使用枚举类型创建单例模式时间却不长. 如果感兴趣, 你可以了解下构建者设计模式和装饰器设计模式。

1) 枚举单例易于书写

这是迄今为止最大的优势,如果你在Java 5之前一直在编写单例, 你知道, 即使双检查锁定, 你仍可以有多个实例。虽然这个问题通过 Java 内存模型的改进已经解决了, 从 Java 5 开始的 volatile 类型变量提供了保证, 但是对于许多初学者来说, 编写起来仍然很棘手。与同步双检查锁定相比,枚举单例实在是太简单了。如果你不相信, 那就比较一下下面的传统双检查锁定单例和枚举单例的代码:

在 Java 中使用枚举的单例

这是我们通常声明枚举的单例的方式,它可能包含实例变量和实例方法,但为了简单起见,我没有使用任何实例方法,只是要注意,如果你使用的实例方法且该方法能改变对象的状态的话, 则需要确保该方法的线程安全。默认情况下,创建枚举实例是线程安全的,但 Enum 上的任何其他方法是否线程安全都是程序员的责任。

/**
* 使用 Java 枚举的单例模式示例
*/
public enum EasySingleton{
    INSTANCE;
}

你可以通过EasySingleton.INSTANCE来处理它,这比在单例上调用getInstance()方法容易得多。

具有双检查锁定的单例示例

下面的代码是单例模式中双重检查锁定的示例,此处的 getInstance() 方法检查两次,以查看 INSTANCE 是否为空,这就是为什么它被称为双检查锁定模式,请记住,双检查锁定是代理之前Java 5,但Java5内存模型中易失变量的干扰,它应该工作完美。

/**
* 单例模式示例,双重锁定检查
*/
public class DoubleCheckedLockingSingleton{
     private volatile DoubleCheckedLockingSingleton INSTANCE;

     private DoubleCheckedLockingSingleton(){}

     public DoubleCheckedLockingSingleton getInstance(){
         if(INSTANCE == null){
            synchronized(DoubleCheckedLockingSingleton.class){
                //double checking Singleton instance
                if(INSTANCE == null){
                    INSTANCE = new DoubleCheckedLockingSingleton();
                }
            }
         }
         return INSTANCE;
     }
}

你可以调用DoubleCheckedLockingSingleton.getInstance() 来获取此单例类的访问权限。

现在,只需查看创建延迟加载的线程安全的 Singleton 所需的代码量。使用枚举单例模式, 你可以在一行中具有该模式, 因为创建枚举实例是线程安全的, 并且由 JVM 进行。

人们可能会争辩说,有更好的方法来编写 Singleton 而不是双检查锁定方法, 但每种方法都有自己的优点和缺点, 就像我最喜欢在类加载时创建的静态字段 Singleton, 如下面所示, 但请记住, 这不是一个延迟加载单例:

单例模式用静态工厂方法

这是我最喜欢的在 Java 中影响 Singleton 模式的方法之一,因为 Singleton 实例是静态的,并且最后一个变量在类首次加载到内存时初始化,因此实例的创建本质上是线程安全的。

/**
* 单例模式示例与静态工厂方法
*/
public class Singleton{
    //initailzed during class loading
    private static final Singleton INSTANCE = new Singleton();

    //to prevent creating another instance of Singleton
    private Singleton(){}

    public static Singleton getSingleton(){
        return INSTANCE;
    }
}

你可以调用 Singleton.getSingleton() 来获取此类的访问权限。

2) 枚举单例自行处理序列化

传统单例的另一个问题是,一旦实现可序列化接口,它们就不再是 Singleton, 因为 readObject() 方法总是返回一个新实例, 就像 Java 中的构造函数一样。通过使用 readResolve() 方法, 通过在以下示例中替换 Singeton 来避免这种情况:

//readResolve to prevent another instance of Singleton
private Object readResolve(){
    return INSTANCE;
}

如果 Singleton 类保持内部状态, 这将变得更加复杂, 因为你需要标记为 transient(不被序列化),但使用枚举单例, 序列化由 JVM 进行。

3) 创建枚举实例是线程安全的

如第 1 点所述,因为 Enum 实例的创建在默认情况下是线程安全的, 你无需担心是否要做双重检查锁定。

总之, 在保证序列化和线程安全的情况下,使用两行代码枚举单例模式是在 Java 5 以后的世界中创建 Singleton 的最佳方式。你仍然可以使用其他流行的方法, 如你觉得更好, 欢迎讨论。

7. 编写 Java 程序时, 如何在 Java 中创建死锁并修复它？

经典但核心Java面试问题之一。

如果你没有参与过多线程并发 Java 应用程序的编码，你可能会失败。

（视频教程推荐：java课程）

如何避免 Java 线程死锁？

如何避免 Java 中的死锁？是 Java 面试的热门问题之一, 也是多线程的编程中的重口味之一, 主要在招高级程序员时容易被问到, 且有很多后续问题。尽管问题看起来非常基本, 但大多数 Java 开发人员一旦你开始深入, 就会陷入困境。

面试问题总是以“什么是死锁？”开始

当两个或多个线程在等待彼此释放所需的资源(锁定)并陷入无限等待即是死锁。它仅在多任务或多线程的情况下发生。

如何检测 Java 中的死锁？

虽然这可以有很多答案, 但我的版本是首先我会看看代码, 如果我看到一个嵌套的同步块，或从一个同步的方法调用其他同步方法, 或试图在不同的对象上获取锁, 如果开发人员不是非常小心，就很容易造成死锁。

另一种方法是在运行应用程序时实际锁定时找到它, 尝试采取线程转储,在 Linux 中,你可以通过kill -3命令执行此操作, 这将打印应用程序日志文件中所有线程的状态, 并且你可以看到哪个线程被锁定在哪个线程对象上。

你可以使用 fastthread.io 网站等工具分析该线程转储, 这些工具允许你上载线程转储并对其进行分析。

另一种方法是使用 jConsole 或 VisualVM, 它将显示哪些线程被锁定以及哪些对象被锁定。

如果你有兴趣了解故障排除工具和分析线程转储的过程, 我建议你看看 Uriah Levy 在多元视觉(PluraIsight)上《分析 Java 线程转储》课程。旨在详细了解 Java 线程转储, 并熟悉其他流行的高级故障排除工具。

（）

编写一个将导致死锁的Java程序？

一旦你回答了前面的问题,他们可能会要求你编写代码,这将导致Java死锁。

这是我的版本之一

/**
 * Java 程序通过强制循环等待来创建死锁。
 *
 *
 */
public class DeadLockDemo {

    /*
     * 此方法请求两个锁,第一个字符串,然后整数
     */
     public void method1() {
        synchronized (String.class) {
            System.out.println("Aquired lock on String.class object");

            synchronized (Integer.class) {
                System.out.println("Aquired lock on Integer.class object");
            }
        }
    }


    /*
     * 此方法也请求相同的两个锁,但完全
     * 相反的顺序,即首先整数,然后字符串。
     * 如果一个线程持有字符串锁,则这会产生潜在的死锁
     * 和其他持有整数锁,他们等待对方,永远。
     */
     public void method2() {
        synchronized (Integer.class) {
            System.out.println("Aquired lock on Integer.class object");

            synchronized (String.class) {
                System.out.println("Aquired lock on String.class object");
            }
        }
    }
}

如果 method1() 和 method2() 都由两个或多个线程调用,则存在死锁的可能性, 因为如果线程 1 在执行 method1() 时在 Sting 对象上获取锁, 线程 2 在执行 method2() 时在 Integer 对象上获取锁, 等待彼此释放 Integer 和 String 上的锁以继续进行一步, 但这永远不会发生。

此图精确演示了我们的程序, 其中一个线程在一个对象上持有锁, 并等待其他线程持有的其他对象锁。

你可以看到, Thread1 需要 Thread2 持有的 Object2 上的锁,而 Thread2 希望获得 Thread1 持有的 Object1 上的锁。由于没有线程愿意放弃, 因此存在死锁, Java 程序被卡住。

其理念是, 你应该知道使用常见并发模式的正确方法, 如果你不熟悉这些模式,那么 Jose Paumard 《应用于并发和多线程的常见 Java 模式》是学习的好起点。

如何避免Java中的死锁？

现在面试官来到最后一部分, 在我看来, 最重要的部分之一; 如何修复代码中的死锁？或如何避免Java中的死锁？

如果你仔细查看了上面的代码,那么你可能已经发现死锁的真正原因不是多个线程, 而是它们请求锁的方式, 如果你提供有序访问, 则问题将得到解决。

下面是我的修复版本,它通过避免循环等待，而避免死锁, 而不需要抢占, 这是需要死锁的四个条件之一。

public class DeadLockFixed {

    /**
     * 两种方法现在都以相同的顺序请求锁,首先采用整数,然后是 String。
     * 你也可以做反向,例如,第一个字符串,然后整数,
     * 只要两种方法都请求锁定,两者都能解决问题
     * 顺序一致。
     */
    public void method1() {
        synchronized (Integer.class) {
            System.out.println("Aquired lock on Integer.class object");

            synchronized (String.class) {
                System.out.println("Aquired lock on String.class object");
            }
        }
    }

    public void method2() {
        synchronized (Integer.class) {
            System.out.println("Aquired lock on Integer.class object");

            synchronized (String.class) {
                System.out.println("Aquired lock on String.class object");
            }
        }
    }
}

现在没有任何死锁,因为两种方法都按相同的顺序访问 Integer 和 String 类文本上的锁。因此,如果线程 A 在 Integer 对象上获取锁, 则线程 B 不会继续, 直到线程 A 释放 Integer 锁, 即使线程 B 持有 String 锁, 线程 A 也不会被阻止, 因为现在线程 B 不会期望线程 A 释放 Integer 锁以继续。（实用详尽的Java面试题大全，可以在Java知音公众号回复“面试题聚合”）

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

任何序列化该类的尝试都会因NotSerializableException而失败，但这可以通过在 Java中 为 static 设置瞬态(trancient)变量来轻松解决。

Java 序列化相关的常见问题

Java 序列化是一个重要概念, 但它很少用作持久性解决方案, 开发人员大多忽略了 Java 序列化 API。根据我的经验, Java 序列化在任何 Java核心内容面试中都是一个相当重要的话题, 在几乎所有的网面试中, 我都遇到过一两个 Java 序列化问题, 我看过一次面试, 在问几个关于序列化的问题之后候选人开始感到不自在, 因为缺乏这方面的经验。

他们不知道如何在 Java 中序列化对象, 或者他们不熟悉任何 Java 示例来解释序列化, 忘记了诸如序列化在 Java 中如何工作, 什么是标记接口, 标记接口的目的是什么, 瞬态变量和可变变量之间的差异, 可序列化接口具有多少种方法, 在 Java 中,Serializable 和 Externalizable 有什么区别, 或者在引入注解之后, 为什么不用 @Serializable 注解或替换 Serializalbe 接口。

在本文中,我们将从初学者和高级别进行提问, 这对新手和具有多年 Java 开发经验的高级开发人员同样有益。

关于Java序列化的10个面试问题

大多数商业项目使用数据库或内存映射文件或只是普通文件, 来满足持久性要求, 只有很少的项目依赖于 Java 中的序列化过程。无论如何,这篇文章不是 Java 序列化教程或如何序列化在 Java 的对象, 但有关序列化机制和序列化 API 的面试问题, 这是值得去任何 Java 面试前先看看以免让一些未知的内容惊到自己。

Für diejenigen, die mit der Java-Serialisierung nicht vertraut sind: Java-Serialisierung ist der Prozess, der zum Serialisieren von Objekten in Java verwendet wird, indem der Status des Objekts in einer Datei mit der Erweiterung .ser gespeichert wird. Über diese Datei ist es möglich, Java wiederherzustellen und zu rekonstruieren Objektstatus, dieser umgekehrte Prozess wird Deserialisierung genannt.

Was ist Java-Serialisierung? Bei der Serialisierung wird ein Objekt in ein Binärformat geändert, das auf der Festplatte gespeichert oder über das Netzwerk an andere laufende Java-Virtual-Maschinen gesendet werden kann. Der Objektstatus kann durch Deserialisierung wiederhergestellt werden Die Java-API bietet Entwicklern einen Standardmechanismus für die Objektserialisierung über die Schnittstellen java.io.Serializable und java.io.Externalizable. Java-Programmierer können die Standardserialisierung basierend auf Klassenstrukturen oder ihrem eigenen definierten Binärformat wählen Letzteres gilt im Allgemeinen als die beste Vorgehensweise, da das serialisierte Binärdateiformat Teil der Klassenausgabe-API wird, wodurch die Kapselung privater und paketsichtbarer Eigenschaften in Java unterbrochen werden kann.

Wie man Klassen serialisiert In Java kann Ihre Java-Klasse nur die java.io.Serializable-Schnittstelle implementieren, und die JVM serialisiert das Object-Objekt im Standardformat. Die Serialisierung einer Klasse erfordert möglicherweise eine lange Zeit -Term-Kosten und können Sie daher daran hindern, ihre Implementierung zu ändern oder zu ändern. Wenn Sie die Struktur einer Klasse ändern, indem Sie eine Schnittstelle hinzufügen, indem Sie sie implementieren, kann das Hinzufügen oder Entfernen von Feldern die Standardserialisierung zerstören, was durch benutzerdefinierte Binärformate erfolgen kann Minimieren Sie die Möglichkeit von Inkompatibilitäten, erfordern aber dennoch erhebliche Anstrengungen, um die Abwärtskompatibilität sicherzustellen. Ein Beispiel dafür, wie die Serialisierung Ihre Fähigkeit zum Ändern einer Klasse einschränkt, ist SerialVersionUID.

Wenn Sie die SerialVersionUID nicht explizit deklarieren, generiert die JVM ihre Struktur basierend auf der Klassenstruktur, die von der Klassenimplementierungsschnittstelle und mehreren anderen Faktoren abhängt, die sich ändern können. Unter der Annahme, dass Ihre neue Version der Klassendatei eine andere Schnittstelle implementiert, generiert die JVM eine andere SerialVersionUID und wenn Sie versuchen, das alte, von der alten Version des Programms serialisierte Objekt zu laden, erhalten Sie eine InvalidClassException.

Dies ist die am häufigsten gestellte Frage in Interviews zur Java-Serialisierung. Nachfolgend finden Sie meine Version. Externalizable stellt uns die Methoden writeExternal() und readExternal() zur Verfügung, die uns eine flexible Kontrolle über den Java-Serialisierungsmechanismus geben, anstatt uns auf die Standard-Serialisierung von Java zu verlassen. Durch die korrekte Implementierung der Externalizable-Schnittstelle kann die Leistung Ihrer Anwendung erheblich verbessert werden.

Serialisierbare Serializalbe-Schnittstelle ist im Paket java.io enthalten und bildet den Kern des Java-Serialisierungsmechanismus. Es verfügt über keine Methoden und wird in Java auch als getaggte Schnittstelle bezeichnet. Wenn eine Klasse die Schnittstelle java.io.Serializable implementiert, wird sie in Java serialisierbar und weist den Compiler an, dieses Objekt mithilfe des Java-Serialisierungsmechanismus zu serialisieren.

Eine meiner liebsten Interviewfragen zur Java-Serialisierung. serialVersionUID ist eine private statische endgültige lange ID. Wenn sie auf das Objekt gedruckt wird, ist es normalerweise der Hash-Code des Objekts. Sie können das JDK-Tool serialver verwenden, um die serialVersionUID des serialisierten Objekts anzuzeigen. SerialVerionUID wird für die Objektversionierung verwendet. Die serialVersionUID kann auch in der Klassendatei angegeben werden. Wenn Sie serialVersionUID nicht angeben, hat dies zur Folge, dass die serialisierte Klasse nicht wiederhergestellt wird, wenn Sie ein Feld in der Klasse hinzufügen oder ändern, da die für die neue Klasse und das alte serialisierte Objekt generierte serialVersionUID unterschiedlich sein wird. Der Java-Serialisierungsprozess basiert auf der korrekten Serialisierung des Objekts, um den Status wiederherzustellen, und löst eine java.io.InvalidClassException aus, wenn die serielle Version des serialisierten Objekts nicht übereinstimmt. Weitere Informationen zu serialVersionUID finden Sie in diesem Artikel, FQ erforderlich.

Eine weitere häufig gestellte Frage im Serialisierungsinterview. Manchmal wird auch gefragt, was eine transiente Variable ist, ob transiente und statische Variablen serialisiert werden usw. Wenn Sie also nicht möchten, dass ein Feld Teil des Status des Objekts ist, deklarieren Sie es als statisch oder transient. Abhängig davon Je nach Bedarf wird dies nicht in den Java-Serialisierungsprozess einbezogen.

Eine einfache Frage zum Java-Serialisierungsprozess. Wenn Sie versuchen, ein Objekt einer Klasse zu serialisieren, die Serializable implementiert, das Objekt jedoch einen Verweis auf eine nicht Serializable-Klasse enthält, wird zur Laufzeit eine NotSerializableException ausgelöst, weshalb ich in meinem Code immer eine Serializable-Warnung (in () eingefügt habe Im Abschnitt „Kommentare“ weist eine der Best Practices für Codekommentare Entwickler an, diese Tatsache zu berücksichtigen, wenn sie neue Felder in serialisierbaren Klassen hinzufügen.

Frage 6) Wenn eine Klasse serialisierbar ist, ihre Oberklasse jedoch nicht, wie ist dann der Zustand der von der Oberklasse geerbten Instanzvariablen nach der Deserialisierung?

Der Java-Serialisierungsprozess wird nur fortgesetzt, wenn die Objekthierarchie eine serialisierbare Struktur ist, dh die serialisierbare Schnittstelle in Java implementiert ist und der Wert der von der Superklasse geerbten Instanzvariablen durch Aufrufen des Konstruktors initialisiert wird Deserialisierung Superklassen, die während der Serialisierung nicht serialisierbar sind. Sobald die Konstruktorverkettung beginnt, kann sie nicht mehr gestoppt werden, sodass der Konstruktor auch dann ausgeführt wird, wenn die Klasse weiter oben in der Hierarchie die serialisierbare Schnittstelle implementiert. Wie Sie der Aussage entnehmen können, sieht diese Frage im Serialisierungsinterview sehr knifflig und schwierig aus, ist aber nicht schwierig, wenn Sie mit den Schlüsselkonzepten vertraut sind.

Frage 7) Ist es möglich, den Serialisierungsprozess anzupassen oder ist es möglich, den Standard-Serialisierungsprozess in Java zu überschreiben?

Die Antwort lautet: Ja, das können Sie. Wir alle wissen, dass Sie zum Serialisieren eines Objekts ObjectOutputStream.writeObject(saveThisObject) aufrufen und ObjectInputStream.readObject() zum Lesen des Objekts verwenden müssen, aber die Java Virtual Machine bietet Ihnen noch eine weitere Möglichkeit, diese beiden Methoden zu definieren. Wenn diese beiden Methoden in einer Klasse definiert sind, ruft die JVM diese beiden Methoden auf, anstatt den Standard-Serialisierungsmechanismus anzuwenden. Hier können Sie das Verhalten der Objektserialisierung und -deserialisierung anpassen, indem Sie beliebige Vor- oder Nachbearbeitungsaufgaben ausführen.

Es ist wichtig zu beachten, dass diese Methoden als privat deklariert werden, um zu vermeiden, dass sie vererbt, überschrieben oder überlastet werden. Da nur die Java Virtual Machine private Methoden Ihrer Klasse aufrufen kann, bleibt die Integrität Ihrer Klasse erhalten und die Java-Serialisierung funktioniert ordnungsgemäß. Meiner Meinung nach ist dies eine der besten Fragen, die Sie in jedem Java-Serialisierungsinterview stellen können, und eine gute Folgefrage ist: Warum ein benutzerdefiniertes Serialisierungsformular für Ihre Objekte bereitstellen?

Frage 8) Unter der Annahme, dass die Superklasse der neuen Klasse die serialisierbare Schnittstelle implementiert, wie kann dann verhindert werden, dass die neue Klasse serialisiert wird?

Eine schwierige Interviewfrage zur Java-Serialisierung. Wenn die Superklasse einer Klasse die serialisierbare Schnittstelle in Java implementiert hat, ist sie in Java bereits serialisierbar. Da Sie die Schnittstelle nicht abbrechen können, ist es nicht möglich, die Klasse tatsächlich deserialisierbar zu machen, aber es gibt eine Möglichkeit, das Neue zu vermeiden Klassenserialisierung. Um die Java-Serialisierung zu vermeiden, müssen Sie die Methoden writeObject() und readObject() in Ihrer Klasse implementieren und von dieser Methode eine NotSerializableException auslösen. Dies ist ein weiterer Vorteil der Anpassung des Java-Serialisierungsprozesses, wie oben in der Frage zum Serialisierungsinterview erwähnt, und wird im Verlauf des Interviews häufig als Folgefrage gestellt.

Frage 9) Welche Methoden werden während des Serialisierungs- und Deserialisierungsprozesses in Java verwendet?

Dies ist eine sehr häufige Interviewfrage, bei der der Interviewer im Wesentlichen bei der Serialisierung Folgendes wissen möchte: Sind Sie mit der Verwendung von readObject(), writeObject(), readExternal() und writeExternal() vertraut? Die Java-Serialisierung erfolgt durch die Klasse java.io.ObjectOutputStream. Bei dieser Klasse handelt es sich um einen Filterstrom, der in einem Bytestrom niedrigerer Ebene gekapselt ist, um den Serialisierungsmechanismus zu handhaben. Um ein beliebiges Objekt über den Serialisierungsmechanismus zu speichern, rufen wir ObjectOutputStream.writeObject(savethisobject) auf, und um das Objekt zu deserialisieren, rufen wir die Methode ObjectInputStream.readObject() auf. Der Aufruf der Methode writeObject() löst den Serialisierungsprozess in Java aus. Bei der readObject()-Methode ist zu beachten, dass sie zum Lesen von Bytes aus der Persistenz, zum Erstellen eines Objekts aus diesen Bytes und zum Zurückgeben eines Objekts verwendet wird, das eine Typumwandlung in den richtigen Typ erfordert.

Frage 10) Angenommen, Sie haben eine Klasse, die serialisiert und in Persistenz gespeichert ist, und dann ändern Sie die Klasse, um ein neues Feld hinzuzufügen. Was passiert, wenn Sie ein serialisiertes Objekt deserialisieren?

Es hängt davon ab, ob die Klasse eine eigene serialVersionUID hat. Wie wir aus der obigen Frage wissen, generiert der Java-Compiler die serialVersionUID, wenn wir sie nicht angeben, und normalerweise entspricht sie dem Hash-Code des Objekts. Durch das Hinzufügen eines neuen Felds besteht die Möglichkeit, dass sich die neue serialVersionUID, die für die neue Version der Klasse generiert wird, vom bereits serialisierten Objekt unterscheidet. In diesem Fall löst die Java-Serialisierungs-API eine java.io.InvalidClassException aus, was der Fall ist Es wird empfohlen, im Code eine eigene serialVersionUID zu haben und sicherzustellen, dass diese innerhalb einer einzelnen Klasse konstant bleibt.

11) Was sind die kompatiblen und inkompatiblen Änderungen im Java-Serialisierungsmechanismus?

Die eigentliche Herausforderung besteht darin, die Klassenstruktur zu ändern, indem mithilfe des serialisierten Objekts ein Feld oder eine Methode hinzugefügt oder ein Feld oder eine Methode entfernt wird. Gemäß der Java Serialization Specification unterliegt das Hinzufügen eines Felds oder einer Methode inkompatiblen Änderungen und Änderungen an der Klassenhierarchie oder der Deimplementierung serialisierbarer Schnittstellen, von denen einige inkompatible Änderungen unterliegen. Für eine vollständige Liste kompatibler und nicht kompatibler Änderungen empfehle ich die Lektüre der Java Serialization Specification.

12) Können wir ein serialisiertes Objekt über das Netzwerk übertragen?

Ja, Sie können serialisierte Objekte über das Netzwerk übertragen, da in Java serialisierte Objekte immer noch in Form von Bytes vorliegen und Bytes über das Netzwerk gesendet werden können. Sie können serialisierte Objekte auch als Blobs auf der Festplatte oder in einer Datenbank speichern.

13) Welche Variablen werden bei der Java-Serialisierung nicht serialisiert?

Diese Frage wird anders gestellt, aber der Zweck ist immer noch derselbe: Kennen Java-Entwickler die Details statischer und transienter Variablen? Da statische Variablen zu Klassen und nicht zu Objekten gehören, sind sie nicht Teil des Objektstatus und werden daher bei der Java-Serialisierung nicht gespeichert. Da die Java-Serialisierung nur den Status des Objekts behält, nicht das Objekt selbst. Transiente Variablen werden auch nicht in den Java-Serialisierungsprozess einbezogen und sind nicht Teil des Serialisierungsstatus des Objekts. Nachdem Sie diese Frage gestellt haben, wird der Interviewer folgende Frage stellen: Wenn Sie den Wert dieser Variablen nicht speichern, welchen Wert haben diese Variablen, wenn Sie diese Objekte deserialisieren und neu erstellen? Das müssen Sie bedenken.

9. Warum muss die Wartemethode in Java in einer synchronisierten Methode aufgerufen werden?

Ein weiteres kniffliges Java-Kernproblem, warten Sie und benachrichtigen Sie es. Sie werden in synchronisiert markierten Methoden oder synchronisierten Blöcken aufgerufen, da „wait“ und „modify“ das Objekt überwachen müssen, für das „wait“ oder „notify-get“ aufgerufen wird.

Die meisten Java-Entwickler wissen, dass die Methoden wait(), notify() und notifyAll() von Objektklassen in synchronisierten Methoden oder synchronisierten Blöcken in Java aufgerufen werden müssen, aber wie oft haben wir darüber nachgedacht, warum in Java warten, notify und Kommt notifyAll aus einem synchronisierten Block oder einer synchronisierten Methode?

Kürzlich wurde einem meiner Freunde in einem Java-Interview diese Frage gestellt. Er dachte darüber nach und antwortete: Wenn wir die Methode wait() oder notify(aus dem synchronisierten Kontext) nicht aufrufen, dann tun wir das wird IllegalMonitorStateException in Java erhalten.

Seine Antwort ist praktisch richtig, aber der Interviewer wird mit einer solchen Antwort nicht ganz zufrieden sein und möchte ihm das Problem erklären. Nach dem Interview haben er und ich das gleiche Thema besprochen und ich dachte, er sollte dem Interviewer von der Race-Bedingung zwischen wait() und notify() in Java erzählen, die bestehen könnte, wenn wir sie nicht in synchronisierten Methoden oder Blöcken aufrufen.

Sehen wir uns an, wie Race Conditions in Java-Programmen auftreten. Dies ist auch eine der beliebtesten Thread-Interviewfragen und kommt sowohl in Telefoninterviews als auch in persönlichen Interviews mit Java-Entwicklern häufig vor. Wenn Sie sich also auf ein Java-Interview vorbereiten, sollten Sie sich auf Fragen wie diese vorbereiten. Ein Buch, das Ihnen wirklich helfen kann, ist das Java Programmer Interview Formula Book. Dies ist ein seltenes Buch, das fast alle wichtigen Themen in Java-Interviews abdeckt, wie z. B. Kern-Java, Multithreading, IO und NIO und Frameworks wie Spring und Hibernate. Sie können es sich hier ansehen.

Warum Wartemethode von synchronisierter Methode in Java? Warum muss Wartemethode von synchronisiertem Block oder Methode in Java aufgerufen werden? Wir verwenden hauptsächlich die Methoden wait(), notify() oder notifyAll() für die Kommunikation zwischen Threads in Java. Ein Thread wartet, nachdem er eine Bedingung überprüft hat. Wenn beispielsweise beim klassischen Producer-Consumer-Problem der Puffer voll ist, wartet der Producer-Thread und der Consumer-Thread benachrichtigt den Producer, nachdem er mithilfe von Elementen oder Threads Platz im Puffer geschaffen hat. Rufen Sie die Methode notify () oder notifyAll () auf, um einzelne oder mehrere Threads darüber zu benachrichtigen, dass sich eine Bedingung geändert hat. Sobald der benachrichtigende Thread den synchronisierten Block verlässt, beginnen alle wartenden Threads, die Warteobjektsperre zu erhalten, und der glückliche Thread erhält sie nach der Sperre erneut , kehren Sie von der Methode wait() zurück und fahren Sie fort.

Lassen Sie uns den gesamten Vorgang in Schritte aufteilen, um die Möglichkeit einer Race-Bedingung zwischen den Methoden wait() und notify() in Java zu erkennen. Wir verwenden das Beispiel eines Produce Consumer-Threads, um das Szenario besser zu verstehen:

• Producer Die Thread-Tests die Bedingung (ob der Puffer voll ist) und bestätigt, dass gewartet werden muss (feststellt, dass der Puffer voll ist).

• Consumer-Thread legt die Bedingung fest, nachdem die Elemente im Puffer verbraucht wurden.

• Der Consumer-Thread ruft die notify()-Methode auf; dies wird nicht gehört, da der Producer-Thread noch nicht wartet.

• Der Producer-Thread ruft die Methode wait() auf und wechselt in den Wartezustand.

Wenn wir also einen Puffer oder nur ein Element verwenden, kann es sein, dass wir aufgrund von Rennbedingungen Benachrichtigungen verlieren. Der Produktionsthread wartet ewig und Ihr Programm bleibt hängen. „Warten auf notify und notifyall in der Java-Synchronisierung. Lassen Sie uns nun überlegen, wie diese potenzielle Race-Bedingung gelöst werden kann? oder notifyAll(), in Java müssen wir die Sperre für das Objekt erwerben, für das wir die Methode aufrufen. Da die Methode wait() in Java die Sperre vor dem Warten aufhebt und die Sperre erneut erhält, bevor sie von wait() zurückkehrt, haben wir dies getan Diese Sperre stellt sicher, dass die Überprüfung der Bedingung (ob der Puffer voll ist) und das Festlegen der Bedingung (Abrufen des Elements aus dem Puffer) atomar sind, was durch die Verwendung synchronisierter Methoden oder Blöcke in Java erreicht werden kann

/**
 *
 * 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");
    }
}