Java Threading and OOP Fundamentals

Valid Java array declarations can place brackets before or after the variable name, but cannot specify array size in the declaration. Option A (public int a []) is valid. Option B (static int [] a) is valid. Option C is invalid - cannot specify [3] in declaration. Option D (public final int [] a) is valid. Option E is wrong syntax ([] must follow type). Option F is invalid - cannot specify [3] in declaration.

To instantiate with new Thing(), the class must have a no-argument constructor. Option A has no explicit constructor, so compiler generates a default no-arg constructor - works. Option C explicitly defines a no-arg constructor - works. Option B is invalid syntax (void is not a valid parameter type). Option D only has a parameterized constructor, so new Thing() won't work.

Default constructor behavior: (A) False - it doesn't initialize method variables, only instance variables. (B) True - default constructor has same access modifier as the class (public class gets public constructor). (C) True - it calls super() implicitly, invoking no-arg superclass constructor. (D) False - if any constructor exists, compiler doesn't create default. (E) True - default constructor only when no other constructors defined.

Option A is valid 1D array initialization. Option B has two errors: missing inner braces for 2D structure, and incorrect syntax - should be {{2,7,6}, {9,3,45}}. Option C is valid String array. Option D is invalid - cannot specify size [3] when using array initialization syntax; either use new boolean[3] or the initialization syntax, not both.

The private A instance (myA) can only become eligible for GC when the Alpha instance containing it becomes eligible. Option A is misleading - explicitly setting myA to null within tryIt() doesn't happen (the method sets a local parameter to null, not myA itself). Option B is correct - when Alpha is GC'd, its private myA field becomes unreachable and eligible for GC. Option C is false - tryIt() doesn't affect myA's reachability.

Encapsulation provides two key benefits: (A) True - hiding implementation details behind public methods. (C) True - internal changes don't break client code as long as the public interface remains stable. Option B is false - you need access modifiers (private/protected) to encapsulate. Option D is false - clients access via methods, not directly. Option E is false - encapsulation may add slight overhead from getter/setter calls.

The code creates a new HelloThread object and calls start(), which spawns a new thread and invokes run(). The run() method prints "Hello from a thread!". This is standard Java threading - the Thread class's start() method creates the thread and calls run() in the new execution context.

Thread.sleep() accepts milliseconds as the parameter, but the actual precision depends on the OS and JVM implementation. The sleep duration is not guaranteed to be exact due to thread scheduling, timer resolution, and system-specific factors. The method may sleep longer than requested but not shorter.

Threads in Java can be created by extending the Thread class and overriding its run() method, or by implementing the Runnable interface and passing an instance to a Thread constructor. Runnable is an interface (not a class), so you implement it, not extend it. Throwable is for exceptions, not threads.

The run() method is defined as an abstract method in the java.lang.Runnable interface to represent a task's entry point. The java.lang.Thread class implements Runnable and provides a concrete implementation of run(). Neither Applet nor Throwable declares the run() method as part of their standard contracts.

wait() puts a thread in a waiting state until notified, while sleep() pauses execution for a specified time - both prevent thread execution. stop() is deprecated and unsafe (can cause corruption), and start() begins execution rather than preventing it.

join() makes the current thread wait until the specified thread completes execution. The other options describe priority behavior (A), yielding (B), and sleep behavior (C) - none match join()

In Java, threads inherit a default priority of 5 (NORM_PRIORITY). The range is 1-10, with 5 being the standard default when no priority is explicitly set.

In Java synchronization, a single thread can acquire multiple locks concurrently, and every object is associated with exactly one monitor lock. It is incorrect to claim that all class methods must be synchronized, as developers selectively synchronize code. Variables cannot be synchronized directly; only methods and blocks can use the synchronized keyword.

Preemptive multitasking allows the operating system to interrupt a currently running thread to allocate CPU time to another thread, typically one with a higher priority. This prevents any single thread from monopolizing the processor. Cooperative multitasking, by contrast, relies on threads voluntarily relinquishing control, while obtaining priority is merely an administrative function.

When objects are created on the stack, constructors execute in order of declaration (a1 first, then b1). When main() returns, destructors execute in reverse order (b1's destructor first, then a1's), following the LIFO (Last In, First Out) principle of stack unwinding.

Const data members must be initialized either via an initializer list in the constructor or with in-class initialization (C++11 and later). Since class A has no constructor and const member k is not initialized at declaration, the code fails to compile.