This is my list of the 10 toughest Java interview questions. These questions are mainly from the Java core and do not cover Java EE-related issues. You may know the answers to these tricky Java questions, or not think they challenge your Java knowledge enough, but they are easy questions to ask in various Java interviews, and many programmers, including my friends and colleagues, find difficult to answer. \
1. Why are waits and notifications declared in the Object class instead of Thread?
A tough Java question, how can you answer it if you didn’t design the Java programming language? A common sense and deep understanding of Java programming helps answer this tricky interview question about the core aspects of Java.
Why are Wait, notify, and notifyAll defined in the Object class and not in Thread
This is a well-known Java interview question that can be asked by any senior Java developer with 2-4 years of experience.
The great thing about this question is that it reflects the interviewer’s understanding of the waiting mechanism and how well he or she understands the topic. Just like the question of why multiple inheritance is not supported in Java or why strings are final in Java, this question can have multiple answers.
Everyone has some good reason why wait and notify are defined in the Object class. From my interview experience, WAIT and Nofity are still the most confusing for most Java programmers, especially developers who are 2 or 3 years old and would be confused if they asked to use Wait and notify. So, if you go to a Java interview, make sure you have a good understanding of wait and notify and can easily write code using WAIT and understand notification mechanisms through producer-consumer issues or implementing blocking queues.
If you haven’t read why wait and notification need to be called from synchronized blocks or methods, and the differences between wait, sleep, and yield methods in Java, you’ll find it interesting. Why wait, Notify, and notifyAll belong to the Object class? Why shouldn’t they be in the Thread class? Here are some ideas that I think make sense:
1) Wait and Notify are more than just common methods or synchronization tools. More importantly, they are communication mechanisms between two threads in Java. For language designers, the Object class is the right place to declare, if you cannot communicate this mechanism through a Java keyword (such as synchronized) while ensuring that the mechanism is available to every Object. Keep in mind that synchronization and waiting for notifications are two different areas, and don’t think of them as the same or related. While synchronization provides mutual exclusion and ensures the thread-safety of Java classes, Wait and Notify are the communication mechanisms between two threads.
2) Every Object can be locked, which is another reason to declare wait and notify in the Object class instead of Thread.
3) In Java, in order to enter a critical section of code, threads need to lock and wait for the lock. They do not know which threads hold the lock, but just know that the lock is held by a certain thread, and they should wait to acquire the lock, rather than knowing which thread is in the synchronized block and asking them to release the lock.
4) Java is based on the idea of Hoare’s monitor. In Java, all objects have a monitor.
The thread is waiting on the monitor, and to execute the wait, we need two parameters:
- A thread
- A monitor (any object)
In Java design, a thread cannot be specified; it is always the thread running the current code. However, we can specify the monitor (which is what we call the wait object). This is a good design, because if we can make any other thread wait on the desired monitor, this will lead to “intrusion” and make it difficult to design concurrent programs. Remember that in Java, all operations that intrude on another thread’s execution are deprecated (such as the stop method).
2. Why is multiple inheritance not supported in Java?
I find this core Java question difficult to answer because your answer may not satisfy the interviewer, and in most cases the interviewer is looking for key points in the answer that will please the interviewer if you mention them. The key to answering this kind of tricky question in Java is to have the topic ready for the various possible questions that follow.
This is a very classic question, similar to why strings are immutable in Java; The similarity between these two problems is that they are largely the result of design decisions by Java authors.
Consider the following two reasons why Java does not support multiple inheritance:
1) The first reason is the ambiguity surrounding the diamond-shaped inheritance issue, consider that A class A has A foo() method, then B and C derive from A and have their own implementation of foo(), now class D uses multiple inheritance derived from B and C, If we only refer to foo(), the compiler will not be able to decide which foo() it should call. This is also known as the Diamond problem because the inheritance scheme is structured like a Diamond, as shown below:
A foo()
/ \
/ \
foo() B C foo()
\ /
\ /
D foo()
Copy the codeEven if we remove the top A class of diamonds and allow multiple inheritance, we will see the ambiguous side of this problem. If you give this reason to your interviewer, he will ask why C++ supports multiple inheritance but Java does not. Well, in this case, I’ll try to explain to him the second reason I gave below, which is not because of technical difficulty, but more maintainable and clearer design is the driving factor, although this can only be confirmed by the Java language designer, we’re just guessing. The Wikipedia link has some good explanations of how the problem of different language addresses can arise due to the diamond problem when using multiple inheritance.
2) The second and more compelling reason to me is that multiple inheritance does complicate design and cause problems during transformations, constructor chaining, and so on. Assuming there aren’t many cases where you need multiple inheritance, it’s wise to omit it for simplicity. In addition, Java can avoid this ambiguity by using interfaces that support single inheritance. Because the interface has only method declarations and does not provide any implementation, there is only one implementation of a particular method, so there is no ambiguity. (Practical detailed Java interview questions, you can reply to “interview questions aggregation” in Java Zhiyan public account)
3. Why does Java not support operator overloading?
Another similarly thorny Java problem. Why does C++ support operator overloading but not Java? One could argue that the + operator has been overridden in Java for string concatenation; don’t be fooled by these arguments.
Unlike C++, Java does not support operator overloading. Java does not provide programmers with free overloading of standard arithmetic operators such as +, -, *, and /. If you’ve used C++ before, Java has a lot less functionality than C++. For example, Java does not support multiple inheritance, there are no Pointers in Java, and there is no reference passing in Java. A similar question is about Java passing by reference, which is essentially whether Java passes parameters by value or by reference. I don’t know the real reason behind it, but I think there’s some truth to why Java doesn’t support operator overloading.
1) Simplicity and clarity. Clarity is one of the goals of Java designers. The designers didn’t just want to copy the language, but to have a clean, truly object-oriented language. Adding operator overloading certainly makes the design more complex than not, and it can lead to a more complex compiler, or slow down the JVM because it needs to do extra work to recognize what the operators actually mean and reduce the opportunity for optimization to guarantee the behavior of the operators in Java.
2) Avoid programming errors. Java does not allow user-defined operator overloading, because allowing programmers to do so would give multiple meanings to the same operator, which would make the learning curve for any developer steep and things even messier. It has been observed that programming errors increase when the language supports operator overloading, increasing development and delivery times. Since Java and the JVM already carry most of the developer’s responsibilities, such as memory management by providing a garbage collector, it doesn’t make much sense because this feature increases the chance of contaminating code and becoming a source of programming errors.
3)JVM complexity. From the JVM’s point of view, supporting operator overloading makes the problem more difficult. The same thing can be achieved by using method overloading in a more intuitive and cleaner way, so it makes sense not to support operator overloading in Java. Complex JVMS can result in slower JVMS than relatively simple JVMS and reduce the opportunity to optimize code to ensure deterministic operator behavior in Java.
4) Make it easier for development tools to process. This is another benefit of not supporting operator overloading in Java. Omitting operator overloading makes the language easier to work with, which in turn makes it easier to develop tools that work with the language, such as ides or refactoring tools. Refactoring tools in Java are far superior to C++.
4. Why are strings immutable in Java?
My favorite Java interview question, tricky but also very useful. This question is also often asked by some candidates why strings are final in Java.
Strings are immutable in Java because strings are cached in the String pool. Because cached strings are shared among multiple customers, there is always a risk that the actions of one customer will affect all the others. For example, if a piece of code changes the value of String “Test” to “Test,” all other customers will see that value as well. Because String cache performance is an important aspect, you avoid this risk by making the String class immutable.
At the same time, strings are final, so no one can break String class immutability, caching, hashing, and so on by extending and overwriting behavior. Another reason the String class is immutable may be due to HashMap.
Because strings are popular as HashMap keys. It is important for key values to be immutable so that they can be used to retrieve value objects stored in the HashMap. Since HashMap works as a hash, it needs to have the same values for it to work. If the contents of the String are modified after insertion, the mutable String will generate two different hash codes during insertion and retrieval, possibly losing the value object in the Map.
If you are an Indian cricket fan, you may be able to relate to my next sentence. Strings are Java’s VVS Laxman, or very special classes. I have yet to see a Java program written without strings. That’s why a good understanding of Strings is important for Java developers.
The importance and popularity of Strings as data types, transport objects, and middlemen also make this question common in Java interviews.
Why strings are immutable in Java is one of the most frequently asked String access questions in Java. It first discusses what a String is and how a String in Java differs from a String in C and C++, I then turn to what immutable objects are in Java, what are the benefits of immutable objects, why you should use them, and which scenarios you should use.
The same question is sometimes asked: “Why is String final in Java?” In a similar note, if you are preparing for a Java interview, I suggest you check out the Java Programmer Interviewing Guide (4th edition), an excellent resource for advanced and intermediate Java programmers. It covers issues from all the important Java topics, including multithreading, collections, GC, JVM internals, and the Spring and Hibernate frameworks.
As I said, there are many possible answers to this question, and the only designer of the String class can safely answer it. I expected some clues in Joshua Bloch’s Effective Java book, but he didn’t mention it either. I think the following points explain why the String class is immutable or final in Java:
1) Imagine that the string pool has not made the string immutable, it is simply not possible, because in the case of the string pool, a string object/literal such as “Test” has been referenced by many reference variables, so if any of them change the value, the other parameters will automatically be affected, i.e. the hypothesis
String A="Test";
String B="Test";
Copy the codeNow string B calls “Test”.toupperCase (), changing the same object to “Test”, so A is also “Test”, which is not the desired result.
The following figure shows how to create strings in heap memory and string pools.
2) Strings are widely used as arguments to many Java classes, for example, to open a network connection you can pass hostname and port number as strings, you can pass database URL as strings to open a database connection, You can open any File in Java by passing the filename as an argument to the File I/O class. If String were not immutable, this would lead to a serious security threat, by which I mean that someone could access any file he had the right to authorize, and then could either intentionally or accidentally change the file name and gain access to that file. Because of immutability, you don’t have to worry about this threat. This is why strings are final in Java. By making java.lang.String final, the Java designers make sure that no one overrides any behavior of the String class.
3) Because String is immutable, it can safely share many threads, which is important for multithreaded programming. It also avoids synchronization problems in Java, and immutability also makes String instances thread-safe in Java, meaning you don’t need to synchronize String operations externally. Another important point about strings is the memory leak caused by intercepting the String SubString, which is not a thread-related problem, but is something to be aware of.
4) another reason why strings are immutable in Java is that strings are allowed to cache their hashcode. Immutable strings in Java cache their hashcode and are not recalculated every time String’s hashcode method is called. This makes the HashMap key it uses in the HashMap in Java very fast. In short, because a String is immutable, no one can change its contents after creation, which guarantees that the hashCode of a String is the same multiple times.
5) The absolute most important reason String is immutable is that it is used by the classloading mechanism and therefore has deep and fundamental security concerns. If the String is variable, load “Java. IO. Writer” request may have been changed to load “mil. Vogoon. DiskErasingWriter”. Security and string pooling are the main reasons for making strings immutable. By the way, the above argument is a good answer to another Java interview question: “Why is String final in Java?” To be immutable, you must be final, so that your subclasses don’t break immutability. What do you think?
5. Why are char arrays better than Java strings for storing passwords?
Another tricky String-based Java question that I believe only a few Java programmers can answer correctly. This is a really tough core Java interview question and requires a solid knowledge of String to answer.
This was the question I asked a friend of mine during a Recent Java interview. He is being interviewed for a technical director position and has over 6 years of experience. If you haven’t already, character arrays and strings can be used to store text data, but it’s hard to choose one over the other. But as my friend says, any String question has to have some clue about special properties of the String, such as immutability, which he uses to convince questioners. Here, we’ll explore some of the reasons why you should use char[] to store passwords instead of strings.
String:
1) Since strings are immutable in Java, if you store the password as plain text, it will be available in memory until the garbage collector clears it. And for reusability, there will be strings in the String pool, which will likely remain in memory for a long time, posing a security threat.
Since anyone with access to a memory dump can find the password in clear text, this is another reason you should always use an encrypted password rather than plain text. Since strings are immutable, you cannot change the contents of a string because any changes will produce a new string, and if you use char[], you can set all elements to blank or zero. Therefore, storing passwords in character arrays significantly reduces the security risk of password theft.
2) Java itself recommends using the getPassword() method of JPasswordField, which returns a char[] and the getTex() method, which returns the password in clear text, which is not recommended for security reasons. Follow the Java team’s advice and stick to the standard rather than against it.
3) With String, there is always the risk of printing plain text in a log file or console, but with Array, the contents of the Array are not printed, but its memory location. It’s not a real reason, but it still makes sense.
String strPassword = "Unknown"; char [] charPassword =new char [] {'U'.'n'.'k'.'w'.'o'.'n'};
System.out.println(" character password: "+ strPassword); System.out.println(" Character password: "+ charPassword);Copy the codeThe output
String Password: Unknown Character password: [c@110b053
Copy the codeI also recommend using a hashed or encrypted password instead of plain text, and purging it from memory as soon as validation is complete. Therefore, in Java, character arrays are a better choice for storing passwords than strings. Although using char[] alone is not enough, you also need to erase the content to be more secure. (Practical detailed Java interview questions, you can reply to “interview questions aggregation” in Java Zhiyan public account)
6. How do I create thread-safe singletons in Java using double-checked locking?
This Is also a common Java question: what is a thread-safe singleton and how do you create it? Well, in versions prior to Java 5, when Singleton instances were created using double-checked locking, multiple Singleton instances could be created if multiple threads tried to create Singleton instances at the same time. Starting with Java 5, it is easy to create thread-safe singletons using enUms. But if the interviewer insists on double-checked locking, then you have to code for them. Remember to use volatile variables.
Why is enumeration singletons better in Java
Enumeration singletons are a new way to implement a singleton pattern in Java using an instance. Although the singleton pattern in Java has been around for a long time, enumerated singletons are a relatively new concept, in practice since Java5, after the introduction of Enum as a keyword and functionality. This article is somewhat related to the previous article on Singleton, which discussed common interview questions about the Singleton pattern, as well as 10 Examples of Java enumerations, where we saw how generically enumerations can. This article is about why we should use Eeame as a singleton in Java, how it benefits over traditional singleton methods, and more.
Java enumerations and singleton patterns
The enumeration singleton pattern in Java is the implementation of a singleton pattern in Java using enumerations. Singleton patterns have long been used in Java, but the creation of singleton patterns using enumerated types has not been for a long time. If you’re interested, take a look at the Builder design pattern and the decorator design pattern.
1) Enumeration singletons are easy to write
This is by far the biggest advantage, if you were writing singletons before Java 5, you know you can still have multiple instances even with double-checked locking. While this issue has been addressed through improvements to the Java memory model, and the availability of volatile variables since Java 5, it is still tricky to write for many beginners. Enumerating singletons is too simple compared to synchronizing double-checked locking. If you don’t believe me, compare the following code for a traditional double-checked locking singleton with an enumeration singleton:
Singletons that use enumerations in Java
This is how we normally declare singletons of enumerations, which may contain instance variables and instance methods, but for the sake of simplicity I haven’t used any instance methods, just note that if you are using instance methods that can change the state of an object, you need to make that method thread-safe. By default, creating instances of enumerations is thread-safe, but whether any other methods on enums are thread-safe is the responsibility of the programmer.
/** * a singleton pattern example using Java enumeration */
public enum EasySingleton{
INSTANCE;
}
Copy the codeYou can handle it with easysingleton.instance, which is much easier than calling the getInstance() method on a singleton.
Example of a singleton with double-checked locking
The following code is an example of double-checked locking in singleton mode, where the getInstance() method checks twice to see if INSTANCE is empty, which is why it is called double-checked locking mode, remember that double-checked locking is proxy-pre-Java 5, but Java5 memory model in volatile variables interference, it should work perfectly.
/** * Example of singleton mode, double lock check */
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 = newDoubleCheckedLockingSingleton(); }}}returnINSTANCE; }}Copy the code. You can call the DoubleCheckedLockingSingleton getInstance () to obtain the singleton class access.
Now, just look at the amount of code required to create a lazy-loaded thread-safe Singleton. With the enumeration singleton pattern, you can have this pattern in a row because the creation of enumeration instances is thread-safe and is done by the JVM.
One could argue that there are better ways to write Singleton than double-checked locking methods, but each method has its own advantages and disadvantages, like my favorite static field Singleton created at class load time, as shown below, but keep in mind that this is not a lazy load Singleton:
The singleton pattern uses the static factory method
This is one of my favorite ways to influence the Singleton pattern in Java, because Singleton instances are static and the last variable is initialized when the class is first loaded into memory, so instance creation is essentially thread-safe.
/** * singleton pattern example with static factory method */
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(){
returnINSTANCE; }}Copy the codeYou can get access to this class by calling singleton.getSingleton ().
2) Enumeration singletons handle serialization themselves
Another problem with traditional singletons is that once serializable interfaces are implemented, they are no longer singletons, because the readObject() method always returns a new instance, just like constructors in Java. Avoid this by using the readResolve() method by replacing Singeton in the following example:
//readResolve to prevent another instance of Singleton
private Object readResolve(){
return INSTANCE;
}
Copy the codeIf the Singleton class remains internal, this becomes more complicated because you need to mark it as transient(not to be serialized), but with enumeration singletons, serialization is done by the JVM.
3) Creating enumeration instances is thread-safe
As mentioned in point 1, because the creation of Enum instances is thread-safe by default, you don’t have to worry about double-checked locking.
In summary, enumerating the Singleton pattern in two lines of code is the best way to create a Singleton in the post-Java 5 world, with serialization and thread safety. You can still use other popular methods if you feel better, welcome to discuss.
7. When writing a Java program, how to create a deadlock in Java and fix it?
One of the classic but core Java interview questions.
If you haven’t been involved in coding multithreaded concurrent Java applications, you may fail.
How do I avoid Java thread deadlocks?
How do I avoid deadlocks in Java? It is one of the most popular interview questions in Java, and also one of the most popular in multi-threaded programming. It is easy to be asked when recruiting senior programmers, and there are many follow-up questions. Although the problem seems pretty basic, most Java developers get bogged down once you start digging.
Interview questions always start with “What is a deadlock?” start
A deadlock occurs when two or more threads are stuck in an infinite wait while waiting for each other to release the required resources (locks). It only occurs when multitasking or multithreading is involved.
How do I detect deadlocks in Java?
While this could have many answers, my version is that first I’ll look at the code, and if I see a nested synchronized block, or call other synchronized methods from one synchronized method, or try to get locks on different objects, it’s easy to cause deadlocks if the developer isn’t very careful.
Another way is to find it when the application is actually locked, and try to take a thread dump. In Linux, you can do this with the kill -3 command, which prints the status of all the threads in the application log file, and you can see which thread is locked to which thread object.
You can analyze this thread dump using tools such as fastThread. IO, which allow you to upload thread dumps and analyze them.
Another approach is to use jConsole or VisualVM, which shows which threads are locked and which objects are locked.
If you are interested in learning about troubleshooting tools and the process of analyzing thread dumps, I recommend Uriah Levy’s Analyzing Java Thread Dumps course at PluraIsight. Designed to learn more about Java thread dumps and familiarize yourself with other popular advanced troubleshooting tools.
Write a Java program that will cause a deadlock?
Once you have answered the previous questions, they may ask you to write code, which will cause a Java deadlock.
This is one of my versions
/** * Java programs create deadlocks by forcing a loop to wait. * * * /
public class DeadLockDemo {
/* * This method requests two locks, the first string, then the integer */
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"); }}}/* * This method also requests the same two locks, but in exactly * reverse order, i.e., integers first, then strings. * If one thread holds a string lock, this creates potential deadlocks * and others hold integer locks, and they wait for each other, forever. * /
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"); }}}}Copy the codeIf method1() and method2() are both called by two or more threads, there is a possibility of deadlocks, because if thread 1 gets a lock on a Sting object while executing method1(), Thread 2, while executing method2(), acquires a lock on the Integer object and waits for each other to release the lock on the Integer and String to proceed, but this never happens.
This diagram accurately illustrates our program in which one thread holds a lock on an object and waits for other object locks held by other threads.
As you can see, Thread1 needs the lock on Object2 held by Thread2, and Thread2 wants the lock on Object1 held by Thread1. Because no thread is willing to give up, there is a deadlock and the Java program is stuck.
The idea is that you should know the right way to use common concurrency patterns, and if you’re not familiar with them, Jose Paumard’s common Java Patterns for Concurrency and Multithreading is a good place to start.
How do I avoid deadlocks in Java?
Now the interviewer comes to the last part, in my opinion, one of the most important parts; How do I fix deadlocks in my code? Or how to avoid deadlocks in Java?
If you take a closer look at the code above, you may have seen that the real cause of deadlocks is not multiple threads, but the way they request locks, and if you provide orderly access, the problem will be solved.
Here is my fix, which avoids deadlocks by avoiding waiting loops without preemption, which is one of the four conditions that require deadlocks.
public class DeadLockFixed {
/** * Both methods now request locks in the same order, taking integers first, then strings. * You can also do the reverse, for example, the first string, then the integer, * as long as both methods request locking, both will solve the problem * in the same order. * /
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"); }}}}Copy the codeThere are no deadlocks now, because both methods access the locks on the Integer and String class text in the same order. Therefore, if thread A acquires A lock on an Integer object, thread B will not continue until thread A releases the Integer lock. Thread A will not be blocked even if thread B holds the String lock. Because now thread B does not expect thread A to release the Integer lock to continue. (Practical detailed Java interview questions, you can reply to “interview questions aggregation” in Java Zhiyan public account)
8. What happens if your Serializable class contains a non-serializable member? How did you solve it?
Any attempt to serialize the class will fail with a NotSerializableException, but this can be easily resolved by setting a transient variable for static in Java.
Frequently asked Questions about Java serialization
Java serialization is an important concept, but it is rarely used as a persistence solution, and developers mostly ignore the Java serialization API. In my experience, Java serialization is a fairly important topic in any Java core interview. In almost every online interview, I have encountered a Java serialization issue or two. I have seen an interview where after asking a few questions about serialization, the candidate became uncomfortable. Because of lack of experience.
They don’t know how to serialize objects in Java, or they’re not familiar with any Java examples to explain serialization, forgetting things like how serialization works in Java, what a tag interface is, what a tag interface is for, the difference between transient variables and mutable variables, How many methods are available for Serializable interfaces, what is the difference between Serializable and Externalizable in Java, or why not use @serializable annotations or replace the Serializalbe interface after the introduction of annotations.
In this article, we will ask questions from both beginners and advanced levels, which are equally beneficial to novices and advanced developers with years of Java development experience.
10 Interview questions about Java serialization
Most commercial projects use database or memory-mapped files or just plain old files to meet persistence requirements, and very few rely on serialization in Java. By all means, this article is not a Tutorial on Java serialization or how to serialize objects in Java, but with interview questions about serialization mechanisms and serialization apis, it’s worth checking out before any Java interview so as not to surprise yourself with something unknown.
For those not familiar with Java serialization, Java serialization is the process used to serialize objects in Java by storing their state to a file with the.ser extension from which Java object state can be restored, This reverse process is called deserialization.
What is Java serialization
Serialization is the process of changing an object into a binary format that can be saved to disk or sent over the network to other running Java virtual machines, and can be restored by deserialization. The Java serialization API provides developers with a standard mechanism through the java.io.Serializable and java.io.Externalizable interfaces, ObjectInputStream and ObjectOutputStream handle object serialization. Java programmers are free to choose between standard serialization based on class structure or their own custom binary format, which is generally considered the best practice because the serialized binary format becomes part of the class output API and can break the encapsulation of private and package-visible properties in Java.
How to serialize
Making classes serializable in Java is simple. Your Java class only needs to implement the java.io.Serializable interface, and the JVM will serialize the Object in the default format. Making a class serializable requires a deliberate effort. Class sequencability can be a long-term cost that restricts you from modifying or changing its implementation. When you change the structure of a class by implementing the add interface, adding or removing any fields may break the default serialization, which can be done by customizing the binary format to minimize the possibility of incompatibilities, but it still takes a lot of effort to ensure backward compatibility. An example of how serialization limits your ability to change a class is the SerialVersionUID.
If SerialVersionUID is not explicitly declared, the JVM generates its structure from the class structure, which depends on the interface the class implements and several other factors that may change. Assuming your new version of the class file implements another interface, the JVM will generate a different SerialVersionUID, and when you try to load the old object serialized by the old version of the program, you will get an InvalidClassException InvalidClassException.
Question 1) What is the difference between serializable and externalizable interfaces in Java?
This is the most frequently asked question in Java serialization interviews. Below, my version of Externalizable gives us the writeExternal() and readExternal() methods, which give us the flexibility to control the Java serialization mechanism rather than relying on Java’s default serialization. Properly implementing the Externalizable interface can significantly improve application performance.
Question 2) How many methods can be serialized? If there are no methods, what is the purpose of a serializable interface?
The serializable Serializalbe interface exists in the java.io package and forms the core of the Java serialization mechanism. It does not have any methods and is also called a tag interface in Java. When a class implements the java.io.Serializable interface, it becomes Serializable in Java and instructs the compiler to serialize the object using the Java serialization mechanism.
Question 3) What is serialVersionUID? If you don’t define this, what happens?
One of my favorite interview questions about Java serialization. SerialVersionUID is a private static final LONG ID that is printed on an object, It is usually the hash code of the object, and you can use the Serialver JDK tool to see the serialVersionUID of the serialized object. SerialVerionUID Is used for object version control. You can also specify the serialVersionUID in the class file. The consequence of not specifying the serialVersionUID is that when you add or modify any field in the class, the serializable class cannot be restored because the serialVersionUID generated for the new class and the old serialized object will be different. The Java serialization process relies on the correct serialized object to restore state, , and in the case of serialized object sequence version mismatch caused by Java. IO. InvalidClassException invalid class is unusual, to understand detailed information on serialVersionUID, please refer to the article, need FQ.
Q4) When serializing, do you want certain members not to be serialized? How do you achieve it?
Another serialized interview question that is often asked. It is also some time to also ask, such as what are transient trasient variables, whether transient and static variables will get serialized, etc., so if you do not want any field to be part of the object’s state, then declare it static or transient according to your needs, so that it is not included in the Java serialization process.
Question 5) What happens if a member of a class does not implement a serializable interface?
A simple question about the Java serialization process. If you try to serialize implement serializable classes of objects, but the object contains an serialization class reference, at run time will trigger an unusually NotSerializableException serialization, this is why I always put a serializable alarm (in my code comments section). One of the best practices for code annotation instructing developers to keep this fact in mind when adding new fields to serializable classes.
Q6) If the class is serializable, but its superclass is not, what is the state of the instance variable inherited from the superclass after deserialization?
The Java serialization process only continues in the object level is all serializable structure, that is, implements the serializable interface in Java, and the value of the instance variable inherited from the super class is initialized by calling the constructor, which is not serializable during deserialization. Once a constructor link will be started, it is impossible to stop, so the constructor will be executed even if the higher class in the hierarchy implements a serializable interface. As you can see from the presentation, this serialized interview question may seem tricky and difficult, but it’s not if you’re familiar with the key concepts.
Q7) Can you customize the serialization process, or can you override the default serialization process in Java?
The answer is yes, you can. As we all know, to serialize an object to call the ObjectOutputStream. WriteObject (saveThisObject), and the ObjectInputStream. ReadObject () reads the object, But one more thing that the Java VIRTUAL machine gives you is to define these two methods. If these two methods are defined in a class, the JVM calls them instead of applying the default serialization mechanism. You can customize the behavior of object serialization and deserialization here by performing any type of pre-processing or post-processing task.
It is important to note that these methods are declared private to avoid being inherited, overridden, or overridden. Since only the Java virtual machine can call a class’s private methods, the integrity of your class will be preserved, and Java serialization will work. In my opinion, this is one of the best questions to ask in any Java serialization interview, and a good follow-up question is, why provide a custom serialization form for your object?
Q8) Assuming that the superclass of the new class implements a serializable interface, how can the new class be prevented from being serialized?
A tricky interview question in Java serialization. If the Super class of a class already implements a serializable interface in Java, then it’s already serializable in Java, because you can’t cancel the interface, it can’t really make it impossible to serialize the class, but there’s a way to avoid serializing the new class. To avoid Java serialization, you need to implement the writeObject() and readObject() methods in your class, and you need to raise the NotSerializableException from that method. This is another benefit of customizing the Java serialization process, as described in the serialization interview question above, and is often asked as a follow-up question as the interview progresses.
Question 9) What methods are used in serialization and deserialization in Java?
This is a common interview question that interviewers are trying to figure out: are you familiar with readObject(), writeObject(), readExternal(), and writeExternal()? Java serialization by Java. IO. ObjectOutputStream class is complete. This class is a filter flow encapsulated in a lower-level byte stream to handle serialization mechanisms. To store any object serialization mechanism, we call the ObjectOutputStream. WriteObject (savethisobject), and deserialize the object, we call it the ObjectInputStream. ReadObject () method. The call triggers the serialization process in Java with the writeObject() method. One important thing to note about the readObject() method is that it is used to read bytes from persistence, create objects from those bytes, and return an object that requires a type cast to the correct type.
Question 10) Suppose you have a class, which is serialized and stored in persistence, and then modify the class to add new fields. What happens if you deserialize a serialized object?
This depends on whether the class has its own serialVersionUID. As we know from the above question, if we do not supply the serialVersionUID, the Java compiler will generate it, usually equal to the object’s hash code. By adding any new fields, the possibility of this new version of the generated new serialVersionUID, unlike has serialized objects, in this case, the Java serialization API will trigger a Java IO. InvalidClassException, Therefore, it is recommended to have your own serialVersionUID in your code and ensure that it is always the same in a single class.
11) What are compatible and incompatible changes in the Java serialization mechanism?
The real challenge is to change the class structure by adding or removing any fields or methods, using serialized objects. According to the Java serialization specification, adding any field or method faces compatible changes and changing class hierarchies or unimplemented serializable interfaces, some under incompatible changes. For a complete list of compatible and incompatible changes, I recommend reading the Java serialization specification.
12) Can we transfer a serialized object over the network?
Yes, you can transfer serialized objects over the network, because Java serialized objects are still preserved as bytes that can be sent over the network. You can also store serialized objects on disk or in a database as bloBs.
13) Which variables were not serialized during Java serialization?
The question is asked differently, but for the same purpose, whether Java developers know the details of static and transient variables. Because static variables are classes, not objects, they are not part of the object state and therefore are not saved during Java serialization. Because Java serialization only preserves the state of the object, not the object itself. Transient variables are also not included in the Java serialization process and are not part of the object’s serialization state. After asking this question, the interviewer then asks, if you don’t store the values of these variables, what is the value of these variables once you deserialize these objects and recreate them? That’s what you have to think about.
9. Why do Java wait methods need to be called from synchronized methods?
Another thorny core Java issue, wait and notify. They are called in methods or synchronized blocks that have synchronized tags, because wait and modify need to monitor the Object on which wait or notify-get is called.
Most Java developers are aware of the wait() for object classes, The notify() and notifyAll() methods must be called from synchronized methods or synchronized blocks in Java, but how many times have we wondered why wait in Java, Do notify and notifyAll come from synchronized blocks or methods?
The problem in the Java interview recently asked a friend of mine, he pondered over and said: if we don’t call from the synchronization context wait () or notify () method, we will receive IllegalMonitorStateException in Java.
His answer was practically correct, but the interviewer was not entirely satisfied with the answer and wanted to explain the problem to him. After the interview he and I discussed the same issue, and I thought he should tell the interviewer about race conditions between wait() and notify() in Java, which might exist if we didn’t call them in synchronized methods or blocks.
Let’s look at how race conditions can occur in a Java program. It is also one of the most popular threading interview questions and often comes up in phone and face-to-face interviews with Java developers. Therefore, if you are preparing for a Java interview, you should prepare such questions, and one book that can really help you is the Java Programmer Interview Formula Book. This is a rare book that covers almost all important topics in Java interviews, such as core Java, multithreading, IO and NIO, and frameworks like Spring and Hibernate. You can check it out here.
Why should a wait method from a Synchronized method in Java be called from a synchronized block or method in Java? We mainly use wait(), notify(), or notifyAll() methods for interthread communication in Java. A thread is waiting after checking a condition; for example, in the classic producer-consumer problem, the producer thread waits if the buffer is full, and the consumer thread notifies the producer thread after creating space in the buffer by using elements. Call notify() or notifyAll() to notify one or more threads that a condition has changed, and once the notification thread leaves the synchronized block, all waiting threads begin acquiring the pending object lock, The lucky thread returns from wait() after reacquiring the lock and continues.
Let’s break the whole operation down into a few steps to see the possibility of competing conditions between wait() and notify() methods in Java, and we’ll use the Produce Consumer thread example to better understand the scenario:
- The Producer thread tests the condition (the buffer is complete) and confirms that it must wait (the buffer is full).
- The Consumer thread sets the condition after using the elements in the buffer.
- The Consumer thread calls notify(); This will not be heard because the Producer thread is not waiting.
- The Producer thread invokes wait() and enters the wait state.
So, because of race conditions, we might lose notifications, if we use buffers or only use one element, the production thread will wait forever, and your program will hang. “Waiting for Notify and NotifyAll in Java synchronization Now let’s consider how to resolve this potential race condition?
This race condition is addressed by using the Synchronized keyword and locking provided by Java. In order to call wait(), notify(), or notifyAll(), in Java we must obtain a lock on the object on which we call the method. Since the Wait () method in Java releases the lock before waiting and reacquires the lock method before returning from wait(), we must use this lock to ensure that the check condition (whether the buffer is full) and the set condition (getting elements from the buffer) are atomic, This can be done by using synchronized methods or blocks in Java.
I’m not sure if this is what the interviewer is actually expecting, but I think it at least makes sense, correct me if I’m wrong, and tell us if there’s any other compelling reason to call wait(), notify(), or notifyAll() in Java.
To summarize, we use Java’s synchronized methods or synchronized blocks to call Java’s wait(), notify(), or notifyAll() methods to avoid:
1) Java throws IllegalMonitorStateException, if we don’t call from synchronization context of wait (), notify () or notifyAll () method.
2) Any potential race conditions between wait and notify methods in Javac.
Can you override static methods in Java? Is it a compile-time error if I create the same method in a subclass?
No, you can’t override static methods in Java, but declaring the exact same method in a subclass is not a compile-time error; it’s called a method hidden in Java.
You cannot override static methods in Java because method override is based on dynamic binding at runtime, and static methods are bound at compile time using static binding. While it is possible to declare a method with the same name and method signature in a subclass, seemingly overwriting static methods in Java, this is actually method hiding. Java does not resolve method calls at run time, and the corresponding method is invoked based on the Object type used to invoke static methods. This means that if you call a static method using the type of the parent class, the original static method will be called from the parent class. On the other hand, if you call a static method using the type of the child class, the method from the child class will be called. In short, you can’t override static methods in Java. If you use A Java IDE like Eclipse or Netbeans, they will display warnings that static methods should be called using class names instead of objects, because static methods cannot be overridden in 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"); }}Copy the codeOutput:
Static method from parent class
This output confirms that you cannot override static methods in Java and that static methods are bound based on type information rather than Object. If static Mehtod is overridden, methods in subclasses or ColorScreen are called. This is all in the discussion and we can override static methods in Java. We have confirmed that no, we cannot override static methods, we can only hide static methods in Java. Creating a static method with the same name and mehtod signature is called a Java hidden method. The IDE displays the warning: “Static methods should be called using class names, not objects,” because static methods cannot be overridden in Java.
These are a list of my core Java interview questions and answers. Some Java questions don’t seem that difficult to experienced programmers, but they can be really difficult to answer for intermediate and novice Java users. By the way, if you encounter any tough Java questions during your interview, please share them with us.
(after)
From: segmentfault.com/a/119000001996266
