Can anyone see anything wrong with this code: Looks good to me. However I'm a little confused - you said you disagree with David Hibbs, that it's not necessary to get rid of synchronizing on the instance variable. But then you proceed to change the synchronization to sync on the Thread instance (this) rather than the instance variable (count). I think David was right, and so is your code - it's better to sync on the Thread instance. In the previous code, Vaibhav wasn't really syncing on the
variable count - he was suncing on the Integer
object which it referenced. The
variable was getting changed all the time, making it refer to different Integer objects - which means that two different threads trying to run the same code could be syncing on different objects, meaning that they could both acquire locks simultanously and thus two threads could be running the same "protected" code at the same time. Not good. In practice I doubt this would cause much real trouble, but it's risky. If you're going to sync on anything, sync on the Tread instance.
I admit, you probably don't even need the call to synchronize (this), Probably true unless it's important that the count be exactly accurate. It may be better to declare count as volatile instead, and drop the synchronization. This allows faster access, while still requiring the variable to be properly updated every time it's accessed. (Otherwise two different threads may be incrementing their own local copies of the variable, only updating the instance variable later - and one thread's update will overwrite the changes made by the other thread.
Even with volatile, there's a minor problem. The ++ operation is not atomic. In order to perform an increment, the JVM must read the value of count from memory, increment it, and store the result back in memory. In between these steps, it's possible for another thread to interrupt (again, even with volatile). If this happens, your count will end up one less than it should be. This will usually be pretty rare, and most of the time no one really cares if the count was 4378 or 4377. So it may be worthwhile to get a slight speed
boost using volatile rather than synchronized, at the cost of a little accuracy.
Note also that if count were long (or double), then forget about using volatile. Too many JVMs do not handle long or double values safely (in violation of the VM Spec). If you want to work with these datatypes safely, you
must use synchronization. Worth remembering if you ever have a
really popular website, requiring a long for the hit count.
The servlet engine can, at its own perrogative, create multiple instances of the same servlet. For example, if it gets 5 requests for the same servlet at once, it's allowed to create two instances of the servlet and split the requests between them. So instead of the last user seeing 5 hits, he/she may see any number from 1 to 5. 
