In a JMeter plan, when do setUp and tearDown Thread Groups run relative to the regular ones?

middlemust knowfreq 61%

answer

Three phases, not one
The engine waits between phases
Same class, different search pass
A Test Plan checkbox guards the last phase

basics

~10 s

Every setUp Thread Group runs and finishes before the first regular Thread Group starts. tearDown Thread Groups start only after all regular threads have stopped. The engine waits between the phases.

solid answer

~50 s

JMeter's engine walks the tree three times, searching separately for SetupThreadGroup, for every AbstractThreadGroup, and for PostThreadGroup. It starts the setUp groups first, then blocks until all of their threads have ended before letting any regular group start. Regular groups run next, and the engine again waits for them all to stop. Only then does it start the tearDown groups. Inside a phase the groups still start in parallel unless the Test Plan's Run Thread Groups consecutively box is ticked. Both special groups are ordinary thread groups otherwise — SetupThreadGroup and PostThreadGroup both extend ThreadGroup, so thread counts, loop counts and the scheduler behave identically. Their panels differ in exactly one field — both SetupThreadGroupGui and PostThreadGroupGui call super(false), which drops the regular group's Delay Thread creation until needed checkbox (ThreadGroup.delayedStart, default false). Otherwise the only difference is which phase the engine puts them in.

JMeter's engine walks the tree three times, searching separately for `SetupThreadGroup`, for every `AbstractThreadGroup`, and for `PostThreadGroup`. It starts the setUp groups first, then blocks until all of their threads have ended before letting any regular group start. Regular groups run next, and the engine again waits for them all to stop. Only then does it start the tearDown groups. Inside a phase the groups still start in parallel unless the Test Plan's *Run Thread Groups consecutively* box is ticked. Both special groups are ordinary thread groups otherwise — `SetupThreadGroup` and `PostThreadGroup` both extend `ThreadGroup`, so thread counts, loop counts and the scheduler behave identically. Their panels differ in exactly one field — both `SetupThreadGroupGui` and `PostThreadGroupGui` call `super(false)`, which drops the regular group's *Delay Thread creation until needed* checkbox (`ThreadGroup.delayedStart`, default false). Otherwise the only difference is which phase the engine puts them in.

code

text · 9 lines

text

INFO o.a.j.e.StandardJMeterEngine: Running the test!
INFO o.a.j.e.StandardJMeterEngine: Starting setUp thread groups
INFO o.a.j.e.StandardJMeterEngine: Starting setUp ThreadGroup: 1 : seed accounts
INFO o.a.j.e.StandardJMeterEngine: Waiting for all setup thread groups to exit
INFO o.a.j.e.StandardJMeterEngine: All Setup Threads have ended
INFO o.a.j.e.StandardJMeterEngine: Starting ThreadGroup: 1 : checkout
INFO o.a.j.e.StandardJMeterEngine: All thread groups have been started
INFO o.a.j.e.StandardJMeterEngine: Starting tearDown thread groups
INFO o.a.j.e.StandardJMeterEngine: Starting tearDown ThreadGroup: 1 : purge test rows

go deeper

for a junior

Remember the order: setUp finishes, then the regular groups run, then tearDown. Knowing that these are still Thread Groups, with the same thread count, loop count and scheduler fields, is enough at this level.

for a middle

Explain the barrier. The engine searches for each kind separately and blocks until a phase's threads have all stopped before the next phase begins, which is why setUp is safe for seeding data the load depends on.

for a senior

Bring the failure mode. Early termination skips tearDown unless the Test Plan option is set, and a forcible stop skips it anyway, so cleanup that must always happen needs a home outside the plan.

for a principal

Decide the policy. If a suite seeds and purges shared state, say whether that belongs in the plan at all or in the pipeline around it, and make the answer consistent across teams so runs cannot poison each other.

Three phases, not one

A JMeter plan can hold three kinds of thread group, and the engine treats them as three sequential phases rather than as three peers in a tree:

setUp Thread Group — the component reference calls it "a special type of ThreadGroup that can be utilized to perform Pre-Test Actions", and says these threads "execute before the test proceeds to the executing of regular Thread Groups".
Thread Group (and Open Model Thread Group) — the measured work.
tearDown Thread Group — "Post-Test Actions", executing "after the test has finished executing its regular Thread Groups".

The boundary between the phases is a hard barrier, not a hint. StandardJMeterEngine runs three separate searches over the tree, starts every setUp group, then calls a wait that blocks until all setUp threads have stopped and logs All Setup Threads have ended before the sampling phase is even marked as started. The same wait separates the regular groups from the tearDown groups.

They are ordinary thread groups

The two special groups are not a different runtime. SetupThreadGroup and PostThreadGroup both extend ThreadGroup, and the manual says outright that "the behavior of these threads is exactly like a normal Thread Group element". So:

they have the same thread count, the same loop count and the same scheduler; the only panel difference is that they omit the regular group's Delay Thread creation until needed checkbox;
they can contain any sampler, controller, config element, assertion or listener a regular group can;
a setUp group with 10 threads really does run 10 threads — it is not silently single-threaded.

That matters, because "do one thing once" is a common intent and a thread group is not the only way to express it: a Once Only Controller runs its children once per thread, not once per test, so ten threads means ten executions.

Ordering inside a phase

Within a phase, groups are started one after another but they overlap — the engine only pauses between groups when the Test Plan's Run Thread Groups consecutively (i.e. one at a time) checkbox is set, which the engine reads as TestPlan.serialize_threadgroups. Two setUp groups therefore run concurrently by default, and the barrier is at the end of the whole phase, not between them.

The tearDown trap

The phase model holds when the test ends normally. It does not hold when the test is ended early:

TestPlan.tearDown_on_shutdown defaults to false, so by default a shutdown of the main threads skips the tearDown phase entirely;
ticking Run tearDown Thread Groups after shutdown of main threads on the Test Plan re-enables it for a graceful shutdown;
the manual adds that if the test is forcibly stopped, tearDown will not run even with the box ticked.

This is the part that bites in practice, because tearDown groups usually hold cleanup — purging seeded rows, releasing a licence, closing a queue. A cancelled run then leaves that debris behind, and the next run starts from dirty state. If cleanup must always happen, it cannot live only in a tearDown Thread Group.

What an interviewer is listening for

"setUp runs to completion first" — not "setUp runs at the top of the tree", which is a statement about layout, not about the engine.
"tearDown runs after all regular threads stopped" — and the caveat that early termination may skip it.
"otherwise they are ordinary thread groups" — because candidates often invent a special single-threaded semantics for them.

The question is a family question, not a scheduling one: the useful takeaway is that these two elements belong to the Threads (Users) family and that their family membership alone fixes where in the run they happen.

## Three phases, not one A JMeter plan can hold three kinds of thread group, and the engine treats them as three sequential phases rather than as three peers in a tree: 1. **setUp Thread Group** — the component reference calls it "a special type of ThreadGroup that can be utilized to perform Pre-Test Actions", and says these threads "execute before the test proceeds to the executing of regular Thread Groups". 2. **Thread Group** (and Open Model Thread Group) — the measured work. 3. **tearDown Thread Group** — "Post-Test Actions", executing "after the test has finished executing its regular Thread Groups". The boundary between the phases is a hard barrier, not a hint. `StandardJMeterEngine` runs three separate searches over the tree, starts every setUp group, then calls a wait that blocks until all setUp threads have stopped and logs `All Setup Threads have ended` before the sampling phase is even marked as started. The same wait separates the regular groups from the tearDown groups. ## They are ordinary thread groups The two special groups are not a different runtime. `SetupThreadGroup` and `PostThreadGroup` both extend `ThreadGroup`, and the manual says outright that "the behavior of these threads is exactly like a normal Thread Group element". So: - they have the same thread count, the same loop count and the same scheduler; the only panel difference is that they omit the regular group's *Delay Thread creation until needed* checkbox; - they can contain any sampler, controller, config element, assertion or listener a regular group can; - a setUp group with 10 threads really does run 10 threads — it is not silently single-threaded. That matters, because "do one thing once" is a common intent and a thread group is not the only way to express it: a Once Only Controller runs its children *once per thread*, not once per test, so ten threads means ten executions. ## Ordering inside a phase Within a phase, groups are started one after another but they overlap — the engine only pauses between groups when the Test Plan's *Run Thread Groups consecutively (i.e. one at a time)* checkbox is set, which the engine reads as `TestPlan.serialize_threadgroups`. Two setUp groups therefore run concurrently by default, and the barrier is at the end of the whole phase, not between them. ## The tearDown trap The phase model holds when the test ends normally. It does not hold when the test is ended early: - `TestPlan.tearDown_on_shutdown` defaults to **false**, so by default a shutdown of the main threads skips the tearDown phase entirely; - ticking **Run tearDown Thread Groups after shutdown of main threads** on the Test Plan re-enables it for a graceful shutdown; - the manual adds that if the test is forcibly stopped, tearDown will not run even with the box ticked. This is the part that bites in practice, because tearDown groups usually hold cleanup — purging seeded rows, releasing a licence, closing a queue. A cancelled run then leaves that debris behind, and the next run starts from dirty state. If cleanup must always happen, it cannot live only in a tearDown Thread Group. ## What an interviewer is listening for - "setUp runs to completion first" — not "setUp runs at the top of the tree", which is a statement about layout, not about the engine. - "tearDown runs after all regular threads stopped" — and the caveat that early termination may skip it. - "otherwise they are ordinary thread groups" — because candidates often invent a special single-threaded semantics for them. The question is a family question, not a scheduling one: the useful takeaway is that these two elements belong to the Threads (Users) family and that their family membership alone fixes where in the run they happen.

You cancel a running JMeter test and the tearDown Thread Group never fires. Why?
The Test Plan property `TestPlan.tearDown_on_shutdown` defaults to false, so an early shutdown skips the tearDown phase. Tick "Run tearDown Thread Groups after shutdown of main threads" to make a graceful shutdown still run it; the manual notes a forcible stop skips it regardless.
Two setUp Thread Groups sit in one plan. Do they run one after the other?
No, not by default. Within a phase the engine starts each group and moves on, so they overlap. Ticking the Test Plan's "Run Thread Groups consecutively (i.e. one at a time)" box makes the engine wait for each group before starting the next.
Why not just use a Once Only Controller instead of a setUp Thread Group?
A Once Only Controller executes its children once per thread, not once per test. With 200 threads you get 200 executions. A setUp Thread Group is a separate phase that finishes before the measured groups start, which is what "once, before the load" actually means.

setUp and tearDown Thread Groups are JMeter's @BeforeAll and @AfterAll: they bracket the measured work and finish before it begins or start after it ends, rather than running alongside it.

saying these in an interview costs you the question

Saying setUp Thread Groups run in parallel with the regular groups
Assuming a tearDown Thread Group always runs, whatever ends the test
Thinking setUp groups are silently single-threaded
Using a Once Only Controller to mean once per test rather than per thread
Believing the special groups need a different set of samplers

In a JMeter plan, when do setUp and tearDown Thread Groups run relative to the regular ones?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

Three phases, not one

They are ordinary thread groups

Ordering inside a phase

The tearDown trap

What an interviewer is listening for

▾common follow-ups3 questions

▾analogy~10 s

▾red flags5 flags

Three phases, not one

They are ordinary thread groups

Ordering inside a phase

The tearDown trap

What an interviewer is listening for

answer

go deeper