Objects and threads are almost orthogonal concepts.  Objects (a.k.a.
class instances) are characterized by their state and behaviors.
Threads are independant sequences of execution, which exercise objects'
behaviors and modify of their state.  The number of threads of execution
to which an object is exposed is not generally a characteristic of that
object -- it is a characteristic of the program using that object.

This all gets a bit muddied in Java because of the java.lang.Thread
class.  It helps to understand that a Thread object does not fully
encapsulate a thread -- it is more of a control panel for one.  The
actual thread is a VM-level / OS-level native entity.

Any live object is uniquely identified by the VM that contains it and
its reference in that VM.  Any Java thread is identified by the VM to
which it belongs and the java.lang.Thread instance associated with it.
A thread is not inherently restricted with regard to which objects it
may examine or modify.

Going back to your earlier questions, I think you have chosen too
complicated a problem.  "Evaluat[ing] the performance of J2EE
applications" simply has too many variables: the computing platform and
its configuration, the specific J2EE implementation and its
configuration, the particular application(s) and application
configuration(s).  Don't forget to choose which aspects of J2EE you want
to evaluate (before you say "all", go read the hundreds, if not
thousands, of pages of the various J2EE specifications).  If you build a
native model then how closely do you intend to model the J2EE app?  If
you plan a very accurate model then you are probably going to have to
build your own J2EE implementation, or an equivalent.  If a less
accurate model then what do you realistically expect to learn from it?

Finally, you need to very clearly understand the technologies involved
to have any hope of producing any a valid evaluation of them.  Your
questions in this newsgroup thread make it clear that you do not have a
good grasp of threading, and that is a very fundamental aspect of what
you want to test.  Moreover, it is unlikely that you will gain the
necessary depth of understanding from Usenet.  Given the breadth of the
problem you are trying to tackle, you are not going to be able to learn
enough fast enough to produce any valid answers before the problem
ceases to be relevant.  I recommend that you narrow the scope.

John Bollinger
jobollin@indiana.edu