No, a new thread is not created unless the programmer commands it so.

A constructor call is synchronous.  That means that the caller waits until the
constructor is finished, then control resumes with the statement or expression
in the caller immediately following the "new" call.

All this happens in the same thread - caller, constructor, and all.

Yes, the object is created in the heap.

All Java objects are created in the heap.

Only if the object's class extends Thread. Even then the construction
runs in the thread where the "new" expression occurs. The new thread
only actually begins to run when its "start" method (inherited from
Thread) is invoked.

All Java objects live on the heap, all of the time, in any compliant
implementation, at least conceptually (meaning it won't matter to you,
the programmer, if as some sort of optimization a temporary object the
JIT compiler statically proves never has references escape the local
context is actually stored on the stack or something -- the semantics
of the language are such that all objects can be assumed to be on the
heap).

References and primitives may exist either in the heap (as fields of
an object) or the stack (local variables and parameters, including the
implicit "final" parameter "this"). If your method has local variables
int x = 3; String y = null; String z = "foo"; then it has an int and
two references on the stack while running, and a single String object
on the heap that exists from the time your class is loaded probably
until the VM exits (string literals are interned). If it also hase
Object w = new Object(); then it has a third reference on the stack,
and each time it runs it creates a new Object on the heap. This object
survives until no longer referenced and then is (not necessarily very
quickly, let alone immediately) garbage collected and goes away. Most
of the times you needn't concern yourself with when it goes away
either -- it won't until you can no longer refer to it or use it
anyway, and it will before letting your app run out of memory. The
main exceptions are:

* Objects like streams that hold resources other than memory, such as
open file handles. The file handle remains open until the object is
garbage collected, which might be a long time after it becomes
unreachable. This can result in a shortage of file handles, or worse,
a delay in writing the last data out to a file. If a user saves their
work and continues editing, then the power goes out, and the stream
used to save their work is still pending garbage collection, the last
piece of the file could be missing when the power comes back on, which
is very, very bad. Uncollected, still-open streams can also cause
stale locks on some filesystems (*cough*Windows*cough*). All objects
that hold resources or have some kind of flush or other "finished with
this" capability should have this done when no longer in use. They
need to be treated as if they were locals, even though they
technically live on the heap: one method running in one thread "owns"
the resource and calls its close, dispose, flush, or whatever method
when done with it. Using try ... finally is strongly recommended to
ensure this is done even if an exception is thrown. Streams and GUI
objects are the only example of this you're likely to encounter either
early in your Java career or regularly. (Creating a new JDialog
repeatedly and never disposing the old ones will leak window handles
on lots of systems. Recycling a single instance will prevent this, as
will disposing each instance after it's closed.) The below other
exceptions about GC timing not affecting program or system behavior
also tend to arise only in more obscure and advanced situations; the
last one is specific to particular, uncommon types of application in
particular deployment circumstances but this next one is encountered
occasionally in general-purpose Java programming.

* Reference objects (java.lang.ref.FooReference) -- the referent can
go away if not referenced in any other way, causing get to return
null. Normally you use this when you specifically don't want to have a
"grip" on the object but just a reference you can use while it still
lives. This includes the keys in WeakHashMap too -- the map's
remaining in use won't stop the key being reclaimed if it's no longer
in use, and the value might then become reclaimable too by no longer
being reachable. This lets you have a mapping associate an object with
a value and still let that object be freed from memory; once it's gone
you can no longer use the mapping anyway so it can go away. (This is
only true for objects that use the default equals and hashCode; value-
type objects should not be used in a WeakHashMap as keys lest the
specific instance used as the key disappear and take the mapping with
it, while other, equal instances remain as possible arguments to the
map's get method, or at least might be constructed in the future.)

* Some high-performance and real-time VM options ensure a responsive
application by limiting the time spent in GC. If objects are created
too rapidly these can run out of memory with dead objects still on the
heap. This is rather silly though -- a full, however-slow emergency GC
hiccuping the app's performance would be vastly preferable to its
outright crashing. Nonetheless some obscure and rarely used VM options
can produce this behavior.

no. The only time a new thread happens in when you say, or indirectly
say, new Thread().start().

Each object you create goes nominally on the heap, though the Jet
compiler sometimes optimises and puts them on the stack. This is
transparent to you.