Unit 5 - Practice Quiz

A stream is an abstraction that represents a sequence of data. In Java, streams are used to read from and write to input and output sources like files, network connections, or the console.

The Scanner class from the java.util package is a versatile and common choice for reading user input from the console.

FileOutputStream is a byte-stream class used for writing raw bytes to a file, making it suitable for binary data like images or executable files.

FileReader is a character-stream class that is used for reading text files. It reads characters instead of raw bytes.

Serialization is the process of converting an object into a byte stream so that it can be stored on disk, sent over a network, or otherwise persisted.

A class must implement the java.io.Serializable marker interface. This interface has no methods; it simply signals to the JVM that the class can be serialized.

Generics enforce type safety at compile time, allowing you to create collections and classes that work with specific types, thus catching type-mismatch errors early and avoiding runtime exceptions.

The correct syntax for declaring a generic class places the type parameter, such as <T>, immediately after the class name.

Introduced in Java 7, the diamond operator <> reduces boilerplate code. For example, instead of List<String> list = new ArrayList<String>(), you can write List<String> list = new ArrayList<>().

The ? is a wildcard that represents an unknown type. A List<?> is a list of some specific but unknown type, making the code more flexible.

This syntax creates a bounded type parameter. It restricts the generic type T to be the Number class or any class that extends Number (like Integer, Double, etc.).

The official states of a Java thread are NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, and TERMINATED. RUNNABLE is the state for a thread that is ready to be executed by the thread scheduler.

Calling the start() method on a thread object allocates system resources, schedules the thread to run, and calls its run() method. This moves the thread from NEW to RUNNABLE.

A thread can be created by extending the java.lang.Thread class and overriding its run() method with the code to be executed.

The Runnable interface is a functional interface that declares a single abstract method: public void run(). This method contains the task that the thread will execute.

Implementing Runnable is more flexible because the class can still extend another class. Extending Thread uses up the single class inheritance slot available in Java.

Java thread priorities range from 1 (MIN_PRIORITY) to 10 (MAX_PRIORITY). The default priority is 5, represented by the constant NORM_PRIORITY.

The synchronized keyword provides a lock on an object, preventing race conditions by ensuring that only one thread can execute a critical section of code at any given moment.

A race condition occurs when multiple threads access shared data concurrently, and at least one of them modifies it. Synchronization controls access to shared resources to prevent this.

The wait() method is a key part of inter-thread communication. It must be called from within a synchronized block. It releases the lock on the object and puts the thread in a waiting state.

BufferedInputStream maintains an internal buffer. When a read request is made, it fills its buffer by reading a large block of data from the underlying FileInputStream. Subsequent reads are then served from this in-memory buffer, minimizing direct, and often costly, I/O operations with the physical disk, thereby improving performance.

The transient keyword marks a field to be excluded from the object's serialized form. When the object is deserialized, this field is not restored from the stream. Instead, it is initialized to its default value for its type. For an object reference type like String, the default value is null.

The wildcard ? extends Number is an upper-bounded wildcard. It means the method accepts a list of Number or any type that is a subtype of Number (like Integer or Double). Since Object is a supertype of Number, not a subtype, passing a List<Object> is a compile-time error.

The operation count++ is not atomic. It consists of three separate steps: read the current value of count, increment the value, and write the new value back. If two threads execute this sequence at the same time, one thread's update might be overwritten by the other. This is a classic race condition. To fix this, the increment() method should be declared as synchronized.

Java supports implementing multiple interfaces but allows extending only one class. By implementing Runnable, your class defining the thread's task is free to extend another class from your application's hierarchy. If you extend Thread, you use up your single inheritance slot. This makes the Runnable approach more flexible and is the preferred object-oriented design.

The wait(), notify(), and notifyAll() methods operate on an object's monitor (lock). A thread must own this lock before it can manipulate the object's wait set. Entering a synchronized block or method acquires the lock. If a thread calls wait() or notify() without holding the lock, the JVM will throw an IllegalMonitorStateException.

The generic class Box<T> provides type safety at compile time. Box<Integer> is correctly instantiated to hold an Integer, and Box<String> is instantiated for a String. The code sets an integer in integerBox and a string in stringBox. The printf statement then correctly retrieves and prints these stored values, demonstrating the proper use of a custom generic class.

A thread transitions to the BLOCKED state specifically when it is waiting to acquire an object's monitor lock. This happens when it tries to execute a synchronized method or enter a synchronized block but the lock is already held by another thread. sleep() leads to TIMED_WAITING, wait() leads to WAITING, and run() completion leads to TERMINATED.

The try-with-resources statement, introduced in Java 7, is the preferred approach. Any resource declared in the try(...) parentheses that implements java.lang.AutoCloseable (which FileWriter does) will be automatically closed at the end of the block. This is more concise and less error-prone than a traditional finally block.

The start() method is the key to achieving concurrency. It requests the JVM and the OS to create a new thread and then makes that new thread execute the run() method. Calling run() directly is just a regular method call. It does not create a new thread and will execute the contents of run() sequentially in the same thread that made the call.

If a serialVersionUID is not explicitly declared, the Java runtime generates one based on the class's structure. If the class is changed (e.g., a field is added), the compiler will generate a new, different ID. When you try to deserialize an old object with the new class definition, the IDs won't match, and an InvalidClassException will be thrown. Declaring an explicit serialVersionUID provides control over class versioning.

The wildcard ? super Integer is a lower-bounded wildcard. It means the list can hold Integers or any supertype of Integer (e.g., Number, Object).

• You can safely add an Integer (or subtype) because any list that holds supertypes of Integer can also hold an Integer.
• You cannot safely get an element and assign it to an Integer because you don't know the list's actual type. It could be List<Object>, and list.get(0) might return a non-Integer. The only type you can safely retrieve an element as is Object.

Synchronizing an entire method locks the whole object (this), which can cause contention if the method is long and only a small part of it accesses shared data. A synchronized block lets you define a smaller critical section. Using a dedicated private lock object (private final Object lock) is a good practice that prevents other, unrelated code from acquiring the same lock, reducing the chance of deadlocks and providing finer-grained control.

The Java specification does not mandate a specific scheduling algorithm. Thread priorities act as suggestions to the underlying operating system's thread scheduler. While a higher-priority thread is generally given preference, this is not a guarantee. The actual behavior can vary significantly between different operating systems (e.g., Windows vs. Linux) and JVM implementations, so code should not rely on priority for correctness.

The notify() method wakes up a single thread that is waiting on the object's monitor. If no threads are currently waiting on that specific object, the notify() call does nothing. The notification is not 'saved' or 'queued' for a future thread that might call wait(). The signal is lost.

A lambda expression like () -> ... can be used to create an instance of a functional interface like Runnable. This Runnable instance is then passed to the Thread constructor. To start execution in a new, concurrent thread, the start() method must be called on the Thread object. Calling run() directly (Option A) executes the code in the current thread. The Runnable interface itself does not have a start() method (Options B and D).

The key distinction is that InputStream/OutputStream are for byte-oriented I/O (raw data), while Reader/Writer are for character-oriented I/O. Reader/Writer classes automatically handle the translation between bytes and 16-bit Java characters based on a specified character encoding. This is crucial for correctly reading and writing text data that may be used across different systems with different default encodings.

The diamond operator <> on the right-hand side of the assignment allows the compiler to infer the generic type arguments from the variable's declaration on the left-hand side. Option A is the pre-Java 7 syntax. Option C uses the var keyword for local variable type inference, introduced in Java 10. Option D uses raw types, which bypasses generic type checking and is discouraged.

This option correctly declares the variable p with specific types String and Integer. It then uses the diamond operator <> for instantiation, and the compiler correctly infers the types from the constructor arguments ("Age" is a String, 25 is an Integer). Option A provides a String ("25") where an Integer is expected. Option C illegally uses type parameters K and V in a variable declaration. Option D has invalid syntax.

Buffered output streams improve performance by collecting data in an in-memory buffer and writing it to the destination (e.g., a file) in larger, more efficient chunks. The flush() method explicitly forces the contents of this buffer to be written out immediately, without waiting for the buffer to become full or for the stream to be closed. This is useful when you need to ensure that data has been physically transmitted.

The primary performance issue here is not at the FileInputStream (byte) level, but at the InputStreamReader (character) level. InputStreamReader itself reads blocks of bytes from the underlying stream (like FileInputStream) into its own internal buffer to perform byte-to-char conversion. However, the while loop calls isr.read() which reads only a single character at a time. This is inefficient. The standard and most effective optimization is to wrap the InputStreamReader in a BufferedReader, like so: BufferedReader br = new BufferedReader(isr);. Then, you can use br.readLine() or br.read(char[] buffer, ...) to read chunks of characters at once, significantly reducing the number of method calls and improving performance. Option B is less effective because InputStreamReader already does some buffering; the main bottleneck is the single-character read() calls. Option A is incorrect because isr.read() does not necessarily make a system call for each character; it reads from its internal buffer. Option D is incorrect because the purpose of InputStreamReader is specifically to handle this decoding correctly; it will read enough bytes from the underlying stream to form complete characters.

This question tests understanding of static, transient, and the serialization process when a superclass is not Serializable.

1. static fields: Static fields belong to the class, not the instance, and are never serialized. When the object m2 is deserialized, the companyName field will have the current value from the Manager class in the deserializing JVM, which is "FINAL Corp".
2. transient fields: The transient keyword prevents a field from being serialized. When m is serialized, the value of accessLevel (20) is ignored. Upon deserialization, the field is initialized to its default value. For an int, the default value is 0.
3. Non-Serializable Superclass: Since Employee is not Serializable, its state (name) is not saved. Instead, during deserialization, the no-argument constructor of the first non-serializable superclass (Employee in this case) is called. Then, the deserialization process restores the state of the Serializable subclass (Manager). The Manager constructor is not called during deserialization. Therefore, the initialization this.accessLevel = 20 does not happen during deserialization. The name field in the deserialized object will be "Default" (from the Employee constructor call).

This question tests the PECS principle (Producer Extends, Consumer Super).

• List<? extends T> list2: This is a producer. You can safely get items from it, and the compiler guarantees they will be of type T or a subtype of T. Therefore, T item = list2.get(0); is valid. You cannot add items to it (except null) because you don't know the exact unknown subtype (e.g., if T is Number, list2 could be List<Integer> or List<Double>, so you can't add an Integer to a List<Double>).
• List<? super T> list1: This is a consumer. You can safely add items of type T (or its subtypes) to it. The list is guaranteed to hold T or a supertype of T. Therefore, list1.add(item); (where item is of type T) is valid. You cannot safely get items from it and assign them to a T variable, because the list could be List<Object> (if T is String), and get(0) would return an Object, which cannot be safely cast to T.

Combining these, T item = list2.get(0); is valid, and list1.add(item); is also valid. The other options are incorrect: B compiles but is less specific than A; C fails because list1.get(0) returns Object, not T, and list2.add(item) is an illegal operation; D fails because list2.add(item) is illegal.

The classic double-checked locking pattern is broken in Java versions prior to Java 5. The issue is subtle and relates to the Java Memory Model. The line instance = new Singleton(); is not atomic. It can be broken down into three steps by the compiler/CPU:

1. Allocate memory for the Singleton object.
2. Call the Singleton constructor to initialize the object.
3. Assign the memory address to the instance variable.

A JIT compiler can reorder steps 2 and 3. A thread (Thread A) could execute step 1 and 3, making instance non-null. Before Thread A has completed step 2 (the constructor), another thread (Thread B) could execute 'Check 1'. It would see instance as non-null and return it. Thread B would then have a reference to an object that has been allocated but not yet fully initialized, which can lead to unpredictable behavior and crashes. To fix this, the instance variable must be declared as volatile (private static volatile Singleton instance;). The volatile keyword ensures that the write to the instance variable happens-before any subsequent read of that variable, preventing this reordering problem. Option C is incorrect because 'Check 2' inside the synchronized block prevents the creation of multiple instances.

The Java documentation for Object.wait() explicitly states that a thread can wake up from wait() without being notified, interrupted, or timing out. This is known as a 'spurious wakeup'. If the condition check is inside an if statement (if (queue.isEmpty()) { wait(); }), and the thread wakes up spuriously, it will exit the if block and proceed as if it were legitimately notified, even though the condition (the queue being non-empty) may still be false. This can lead to errors, such as trying to consume from an empty queue. By placing the wait() call inside a while loop, the thread re-checks the condition upon waking up. If it was a spurious wakeup and the condition is still false, it will immediately call wait() again, correctly handling the situation. Option A is related to lost signals, which is a different problem. Option C is about atomicity, which is handled by the synchronized block itself. Option D is an automatic part of waking from wait(); the thread must re-acquire the lock, but this is not why the while loop is used.

A thread in TIMED_WAITING state is waiting for a specific amount of time for a certain event to occur. Let's analyze the options:

1. t.interrupt(): Calling interrupt() on a thread waiting on a lock (or in sleep/wait) will cause it to wake up, throw an InterruptedException, and transition to the RUNNABLE state. So this causes a transition.
2. Timeout elapses: If the 10 seconds pass and the lock is still not acquired, the tryLock method will return false, and the thread will transition to RUNNABLE. So this causes a transition.
3. Lock becomes available: If another thread releases the lock and t is chosen to acquire it, tryLock will return true, and the thread will transition to RUNNABLE (after a brief BLOCKED state to acquire the lock). So this causes a transition.
4. t.suspend(): The suspend() method is deprecated and should not be used. It causes the thread to halt its execution without releasing any locks it holds. The thread's state becomes RUNNABLE but it is not scheduled for execution by the OS. It does not transition out of TIMED_WAITING in the same way the other events do; it essentially freezes the thread in its current state, which is extremely dangerous and prone to deadlock. The official state transition diagram does not include suspend() because of its deprecated nature. It doesn't follow the normal lifecycle transitions and is considered an unsafe operation.

This question targets the concept of type erasure in Java generics. At runtime, the type parameter T is erased and replaced by its bound, which is Object in this case. The JVM has no information about what T was at compile time. The instanceof operator, however, requires concrete type information at runtime to perform its check. Since T is not available at runtime, the compiler prohibits its use with instanceof. Such types whose information is fully available at runtime are called 'reifiable types' (e.g., String, Integer, raw types, int[]). Generic types like Node<T> or List<String> are non-reifiable. The other options are incorrect. Making the method static wouldn't help as static contexts can't access instance type parameters anyway. Casting obj to T is unsafe and doesn't solve the instanceof issue. The access modifier of T is not the problem.

This is a hard question because it requires understanding the interaction between the JVM and the host OS scheduler. Java thread priorities are not a guarantee of execution order; they are a hint to the thread scheduler.

1. Modern operating systems use preemptive, priority-based scheduling, but they also employ sophisticated algorithms to prevent starvation of lower-priority threads.
2. The JVM maps Java's 10 priority levels to the native priority levels of the OS, but this mapping can be many-to-one (e.g., Windows has 7 priority levels, Linux has many more).
3. A higher priority generally means the thread gets a chance to run more often or for longer time slices, but it does not mean it will monopolize the CPU until it completes. The OS will still interleave the execution of all three threads to ensure fairness and system responsiveness. Therefore, strict sequential execution (Option A) is highly unlikely. The priorities are not completely ignored (Option C), nor is the mapping non-existent (Option D). The most accurate description is that the higher priority thread will be favored by the scheduler, but all three will make progress concurrently.

The core design principle at play is the separation of concerns. In Approach B, the task (what to run) is separated from the execution mechanism (the thread). This is a major advantage because the MyTask object, which is just a Runnable, can be passed to various concurrency utilities. For instance, you can submit it to an ExecutorService for execution in a thread pool (executor.submit(new MyTask())), run it in a plain Thread (new Thread(new MyTask()).start()), or use it with other frameworks. In Approach A, the task logic is tightly coupled with the Thread class itself. You cannot easily reuse the task logic in a thread pool without creating a new MyThread instance, which is less flexible. Option A is incorrect; neither Runnable nor Thread's run() method has a return value (for that, you need Callable). Option C is a minor point and often not the primary driver; the overhead difference is usually negligible. Option D is incorrect; priority can be set on the Thread object in both approaches.

This question highlights a critical difference between Serializable and Externalizable. When deserializing a standard Serializable object, the JVM uses a special mechanism to create the object without invoking its constructor. However, when deserializing an Externalizable object, the process is different. The Externalizable interface gives the class complete control over its serialization format. To facilitate this, the deserialization process must first create a default instance of the object to call the readExternal method on. It does this by invoking the class's public no-argument constructor. If a public no-arg constructor is not available, a java.io.InvalidClassException will be thrown at runtime. After the object is created via its constructor, the readExternal method is called, which is then responsible for reading the data from the stream and populating the object's fields.

The constructor new ReentrantLock(true) creates a fair lock. A fair lock's acquisition order approximates the arrival order of waiting threads. When the lock is released, the scheduler will select the thread that has been waiting the longest to acquire it next. In contrast, a default ReentrantLock (and all synchronized blocks) are unfair. An unfair lock allows 'barging', meaning a newly arriving thread might acquire the lock before a thread that has been waiting for a long time, potentially leading to starvation but often offering higher throughput. Both synchronized and ReentrantLock are reentrant (Option A). Both ReentrantLock(true) and ReentrantLock(false) support lockInterruptibly (Option C), which is a feature synchronized lacks, but this is not the specific difference introduced by the true parameter. The performance claim in Option D is not universally true; while ReentrantLock can offer better performance in some high-contention scenarios, synchronized has been heavily optimized in modern JVMs and can be faster in others.

This is a one-time convergence problem. A group of threads needs to signal a single waiting thread that they have all completed. This is the exact use case for CountDownLatch.

• CountDownLatch: Initialize it with new CountDownLatch(5). Each worker thread calls latch.countDown() upon completion. The master thread calls latch.await(), which will block until the count reaches zero (i.e., all 5 workers are done).
• CyclicBarrier: This is for when a group of threads must all wait for each other at a specific point before proceeding, and it's reusable (cyclic). Here, the master thread is not part of the initial group of workers, and the barrier is not needed after the aggregation, making CountDownLatch a better fit for this one-way, one-time coordination.
• Semaphore: A semaphore controls access to a shared resource; it doesn't coordinate completion of tasks.
• Future objects: While you could use five Futures and have the master thread call get() on each one, this is a more complex implementation. The get() calls would block sequentially. CountDownLatch provides a cleaner, more direct solution for signaling the completion of the entire group.

This question pits a naive generic method against one that correctly uses bounded wildcards (PECS).
Let's analyze the scenario: src is a List<Integer> and dest is a List<Number>.

• Method 1 (List<T> dest, List<T> src): For this method to compile, the compiler must infer a single type T that satisfies both arguments. If src is List<Integer>, T must be Integer. If dest is List<Number>, T must be Number. There is no single T that satisfies both, so the call copy(numberList, integerList) would fail for Method 1.
• Method 2 (List<? super T> dest, List<? extends T> src): This is the signature of Collections.copy(). Here, the compiler can infer T as Integer. Let's check the arguments:
  • src: List<Integer> matches List<? extends Integer>. This is valid.
  • dest: List<Number> matches List<? super Integer>. This is valid because Number is a supertype of Integer.
    Therefore, Method 2 provides the flexibility needed for this operation, while Method 1 is too restrictive. Option A correctly identifies this. Option B is incorrect because you cannot copy supertypes into subtypes. Option C is technically true for both, as copy(objectList, stringList) would cause T to be inferred as Object for Method 1, but A describes a case where only Method 2 works, highlighting its superiority.

Thread.stop() is inherently unsafe and has been deprecated for this reason. When stop() is called, the target thread throws a ThreadDeath error and terminates abruptly, no matter what it was doing. A critical side effect is that it unlocks all monitors (locks) that it has acquired. If the thread was stopped in the middle of a critical section (e.g., inside a synchronized block) where it was modifying a shared data structure, that structure could be left in an inconsistent state. Other threads that subsequently acquire the lock will see this corrupted state, leading to unpredictable and difficult-to-debug errors. While ThreadDeath can be caught (Option A), it's extremely difficult to write correct cleanup code that can run in any arbitrary state. The main danger is the damage to shared objects, as described in Option B.

This scenario describes a need for an atomic 'rename' or 'move' operation to ensure the file replacement is transactional.

• Files.move is the correct operation for renaming a file.
• StandardCopyOption.REPLACE_EXISTING is required to allow the originalPath to be overwritten if it already exists.
• StandardCopyOption.ATOMIC_MOVE is the crucial option here. It specifies that the move operation should be performed atomically. On most modern file systems, renaming a file within the same file system is an atomic metadata operation. This guarantees that there is no intermediate state where the originalPath is deleted but the tempPath has not yet been renamed, which could happen with a non-atomic copy-then-delete approach. A system crash at the wrong moment would be catastrophic without atomicity. Option A is missing ATOMIC_MOVE. Option B uses copy instead of move. Option D writes directly to the file, which is not transactional; if the write fails midway, the original file is left in a corrupted state.

This question tests precise knowledge of the thread lifecycle.

1. When you create a Thread object using new Thread(), you are just creating a Java object. No native OS thread has been created yet. The thread is in the NEW state. It remains in this state until its start() method is invoked.
2. The t.start() method does two things: it registers the new thread with the thread scheduler (which will eventually call its run() method) and then it immediately returns. The thread that called t.start() does not wait for the new thread to begin or finish execution. It continues its own execution path. Therefore, after the start() call returns, the calling thread is still in the RUNNABLE state, ready to execute its next instruction. The new thread t will transition from NEW to RUNNABLE, but this happens asynchronously.

The four Coffman conditions for deadlock are:

1. Mutual Exclusion: Resources (locks) can only be held by one process at a time. (This is fundamental to locking and is not broken).
2. Hold and Wait: A process holds at least one resource and is waiting to acquire additional resources held by other processes. (This is present in the scenario).
3. No Preemption: Resources cannot be forcibly taken from a process; they must be released voluntarily. (This is how Java locks work).
4. Circular Wait: There exists a set of waiting processes {P0, P1, ..., Pn} such that P0 is waiting for a resource held by P1, P1 is waiting for a resource held by P2, ..., and Pn is waiting for a resource held by P0.

The deadlock occurs because T1 waits for L2 (held by T2) and T2 waits for L1 (held by T1), forming a circular dependency. By enforcing a strict global ordering of lock acquisition (e.g., any thread that needs both L1 and L2 must always acquire L1 first), you make it impossible for this circular chain to form. If T2 needs both locks, it would have to acquire L1 first. If T1 already holds L1, T2 will simply block on L1, but it won't be holding L2. Therefore, T1 can proceed to acquire L2, do its work, and release both locks, allowing T2 to proceed. This strategy directly breaks the Circular Wait condition.

This is a subtle edge case regarding the evolution of the diamond operator. In Java 7 (when the diamond was introduced) and Java 8, the compiler could not infer the type arguments for a generic class when it was being instantiated as an anonymous inner class. The compiler would throw an error stating that cannot infer type arguments for Pair. Therefore, in Java 7/8, you would have to explicitly state the type: new Pair<String>(...) { ... };. This limitation was fixed in Java 9 (JEP 213). Starting with Java 9, the compiler is smart enough to infer the type argument from the context (Pair<String> p), allowing the use of the diamond operator with anonymous inner classes. Option A is incorrect about Java 8. Option B is incorrect about Java 9+. Option D is incorrect as anonymous inner classes can certainly extend generic classes.

The Serializable interface is a marker interface, but the serialization mechanism strictly enforces it. When ObjectOutputStream attempts to serialize an object, it recursively traverses the object's graph of instance fields. If it encounters any object that does not implement the Serializable interface, it cannot proceed because there is no contract on how to save that object's state. At this point, the serialization process fails immediately by throwing a NotSerializableException at runtime. The compiler does not check for this, so it is a runtime error, not a compile-time error. The field is not silently skipped; the entire operation fails. To fix this, the programmer must either make the contained class Serializable or mark the field that holds its instance as transient.

The Exchanger is a synchronization point where two threads can meet and swap data. The exchange() method is a blocking call. When the first thread (T1) calls exchange(), it provides its object and then blocks. Internally, it is put into a waiting state by the Exchanger's synchronization mechanism (often using LockSupport.park()). This puts the thread into the WAITING state (if exchange() was called without a timeout) or TIMED_WAITING (if a version with a timeout was used). It is not BLOCKED, which is a state specifically for threads waiting to acquire a monitor lock. It is not RUNNABLE, as it is not eligible for CPU time. It remains in this waiting state until the second thread (T2) arrives and calls exchange(), at which point the swap occurs and both threads are unparked and transition back to RUNNABLE.