In Java concurrency, the statement "A lock can be acquired on a class" refers to synchronizing on the Class object (for example via a static synchronized method). Is this statement true or false?

Introduction / Context:
Java provides intrinsic locks that are associated with every object. When you mark methods as synchronized or use synchronized blocks, you are implicitly or explicitly acquiring these locks. Many developers learn that each instance has its own lock, but they may overlook how locks work for static synchronized methods. This question examines whether it is possible to acquire a lock on a Class object and what that means for thread safety.

Given Data / Assumptions:

• Every Java object, including Class objects, has an associated monitor lock.
• Synchronized instance methods use the lock of the current object.
• Static synchronized methods use the lock of the associated Class object.
• Explicit synchronized blocks can choose any object as a lock, including ClassName.class.

Concept / Approach:
In Java, a Class object represents the loaded class metadata at runtime. Like any other object, it has a monitor that can be used for synchronization. When a method is declared as static synchronized, the Java language specification states that the monitor associated with the Class object for that method declared in class is used as the lock. Additionally, you can synchronise explicitly on ClassName.class in a synchronized block. Therefore, it is correct to say that a lock can be acquired on a class in the sense of synchronizing on its Class object.

Step-by-Step Solution:
Step 1: Recall that synchronized instance methods implicitly acquire the lock of the current object (this) when entered.Step 2: Recall that static synchronized methods implicitly acquire the lock of the Class object that represents the class where the method is defined.Step 3: Recognise that you can also write explicit synchronized blocks such as synchronized (MyClass.class) to acquire the same Class level lock.Step 4: Understand that this lock is shared by all threads across the application for that class, providing mutual exclusion for static operations.Step 5: Conclude that the statement that a lock can be acquired on a class is true in Java concurrency terminology.

Verification / Alternative check:
You can verify this behaviour by writing a small program with a static synchronized method and adding logging that shows threads blocking when they attempt to enter that method concurrently. If you then use a synchronized block on the same Class object in another method, you will see that it contends for the same lock. Official Java documentation and concurrency books describe this pattern explicitly, confirming that Class objects participate in intrinsic locking.

Why Other Options Are Wrong:
Option B states that locks can only be acquired on individual instances and never on Class objects, which contradicts the behaviour of static synchronized methods and synchronized (ClassName.class) blocks. Option C claims both A and B are correct, which is logically impossible because they are mutually exclusive. Option D says none of the options are accurate, but option A matches the documented semantics of Java locking. Therefore, A is the only correct choice.

Common Pitfalls:
A common pitfall is overusing Class level locks, which can create unnecessary contention and reduce scalability, because all threads across the application compete for the same lock. Another mistake is assuming that synchronizing on ClassName.class will also protect operations on different classes or subtypes automatically. Good design often prefers finer grained locking, using separate lock objects or instance level synchronisation when appropriate, while reserving Class level locks for truly global operations.

Final Answer:
Correct answer: True, a lock can be associated with the Class object for static synchronized methods or explicit synchronization on ClassName.class