Runtime & concurrency
Reveal answer and reasoning
The explicit static constructor establishes a defined type-initialization boundary before the first relevant static method invocation proceeds. Counter uses it to set value to two and print init once. This is different from a type relying only on implicit field initialization and possible beforefieldinit timing freedom. The sample intentionally chooses a direct first static method call so its order can be predicted without guessing about a runtime's optimization strategy.
A common wrong answer assumes every mention of a type, every metadata query, or source-file declaration order causes the same initialization behavior. Type identity also matters: separate closed generic constructions can have separate static state. Keep static initialization small and avoid blocking dependencies that may require the same type to finish initializing. A failed initializer is not an ordinary retryable method call.
Desktop output confirms this bounded explicit-constructor sequence, not universal timing for every type under JIT, interpreter, and AOT execution.
What a strong answer covers
- The sample has an explicit static constructor.
- The first static call triggers the required initialization.
- beforefieldinit and other type identities need separate reasoning.
Common pitfall
Assuming all type references and all static-field declarations have identical initialization timing.
Follow-up questions
- Does merely obtaining Type metadata imply the same trigger?
- Why can blocking inside static initialization be dangerous?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.