Some java developers intuitively think a thread maps to an object in JVM (or kernel), and we can control it by calling methods on it (similar to how we control a JDBC connection or JMS session). For both novice and experienced java developers, it can be hard to unlearn that idea.
java.lang.Thread static methods obviously don’t affect any particular “object” , since they are static method. java.lang.Thread instance methods do affect the target thread, in limited ways. The stop/suspend/resume methods are direct actions on an an “instance” but are deprecated. The most fundamential programmatic controls on a thread involve locks and wait/notify, which paradoxically never name the threads they affect. Using these constructs demands that we visualize the affected threads as unassociated with any jvm object including the java.lang.Thread instances.
All experienced multi-threading developers eventually get the idea that a thread is not really associated with any object we create in our source code.
Java confuses us by giving us object-oriented thread creation constructs + thread pool. These make us feel threads are just objects. Well, are ebooks real books?
As explained in my blog on [[programmatic control on threads]], a VM thread has its memory structure residing in the stack space, including program counters and per-thread registers. The Thread.java object we create is a JVM heap object having a pointer to the VM thread. This Thread object is unrelated  to those objects accessible on the VM thread.
VM thread is basically a stack of open method CALLS. Each non-static method call like m1() has a host object (myAccount for eg) but that host object is UNRELATED to the vm thread. However, myAccount can become problematic to our vm thread due to data corruption if
* m1() read/write myAccount fields
* and other vm threads also have method CALLs that read/write fields of this same myAccount instance.
* In addition, m1() often read/write other shared objects like herAccount, while other threads may also read/write herAccount
It’s exactly due to this kind of concurrent access to shared objects (like myAccount) that we end up with locks, wait/notify and all the consistency/liveness issues.
Among vm thread t1, corresponding Thread instance T1, and a regular object U1 on t1, we can say
+ T1 has a pointer to t1, but never to U1
+ t1 has no pointer to T1 or U1. This t1 is not a java object with fields and methods.
+ U1 has no pointer to t1, but the can get a pointer to T1 using Thread.currentThread(). But can it access fields of T1 if you put custom fields into T1? YES. Thread.currentThread() returns the same Thread instance every time.
In conclusion, the Thread.java object is a poor handle on the vm thread. The vm thread is not an object but a call stack. You don’t have a good java object (with fields and methods) manipulating the vm thread. Crucially, the method calls on a vm thread often access shared objects, but these objects are unrelated to the vm thread
 Actually Thread.sleep does affect the current thread but that’s a minor point.
 there’s no pointer between the vm thread and myAccount. If you know myAccount.m1() is running on a vm thread, myAccount.m1() might simultaneously be running on antoher vm thread too.