This is something you should not even worry about, let the container take care of the Threads.
Tomcat maintains a pool of Threads to handle requests, but after a pool Thread returns from handling a request all of the memory consumed by the request object, the response object and any other objects created during the request are available for GC - if you coded the application correctly. So your question:
My question here is Does the method getThreadAllocatedBytes() will get the overall memory usage of the thread since it is created ?
To explain William's explanation in a slightly different way:
Tomcat maintains several thread pools, but the one I think is of most interest to you is the worker pool which contains threads that run JSP and servlet requests.
It is critical for proper operation of Tomcat that each thread in that pool should be 100% interchangeable with any other thread in that pool. That is because threads do not (and MUST not) retain resources when they are in the pool. All resources obtained by an active thread must be released before the thread is returned to the pool. Since threads are assigned on a purely statistical basis, if they aren't interchangeable, they would cause Tomcat to behave in unpredictable ways.
Thus, measuring memory usage of threads as such is a meaningless exercise. What you want to do is measure memory usage of the functions that run under the threads. That is, the application code. Because that's the part that can vary, that's the part that is most likely to cause out-of-memory, and that's the part that if it isn't cleaned up (leaks) will leak to the problems I just mentioned.
And obviously, no two requests are likely to consume exactly the same amount of memory. Especially when they are different types of requests, but depending on that the request process does, even the same type of request can potentially have vastly different memory demands, based on the data involved.
In addition to application code memory usage, Tomcat also has non-pool threads running that will consume and release memory resources, even while no actual web requests are in process. So expect a certain amount of "sawtooth" on the memory usage graphs as these functions run and their resources are garbage-collected.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.