Finalize() method being called multiple times for same object?

Question

I got a dilly of a pickle here.
Looks like according to the Tomcat output log file that the finalize method of class User is being called MANY more times than is being constructed.
Here is the User class:
package com.db.multi;
import java.io.*;
import com.db.ui.*;
import java.util.*;
* @author DBriscoe
public class User implements Serializable {
    private String userName = null;
    private int score = 0;
    private SocketImage img = null;
    private boolean gflag = false;
    private Calendar timeStamp = Calendar.getInstance();
    private static int counter = 0;
    /** Creates a new instance of User */
    public User() { counter++;     
    public User(String userName) {
        this.userName = userName;
        counter++;
    public void setGflag(boolean gflag) {
        this.gflag = gflag;
    public boolean getGflag() {
        return gflag;
    public void setScore(int score) {
        this.score = score;
    public int getScore() {
        return score;
    public void setUserName(String userName) {
        this.userName = userName;
    public String getUserName() {
        return userName;
    public void setImage(SocketImage img) {
        this.img = img;
    public SocketImage getImage() {
        return img;
    public void setTimeStamp(Calendar c) {
        this.timeStamp = c;
    public Calendar getTimeStamp() {
        return this.timeStamp;
    public boolean equals(Object obj) {
        try {
            if (obj instanceof User) {
                User comp = (User)obj;
                return comp.getUserName().equals(userName);
            } else {
                return false;
        } catch (NullPointerException npe) {
            return false;
    public void finalize() {
        if (userName != null && !userName.startsWith("OUTOFDATE"))
            System.out.println("User " + userName + " destroyed. " + counter);
    }As you can see...
Every time a User object is created, a static counter variable is incremented and then when an object is destroyed it appends the current value of that static member to the Tomcat log file (via System.out.println being executed on server side).
Below is the log file from an example run in my webapp.
Dustin
User Queue Empty, Adding User: com.db.multi.User@1a5af9f
User Dustin destroyed. 0
User Dustin destroyed. 0
User Dustin destroyed. 0
User Dustin destroyed. 0
User Dustin destroyed. 0
USER QUEUE: false
INSIDE METHOD: false
AFTER METHOD: false
User Dustin destroyed. 1
User Dustin destroyed. 1
User Dustin destroyed. 1
User Dustin destroyed. 1
USER QUEUE: false
INSIDE METHOD: false
AFTER METHOD: false
User Dustin destroyed. 2
User Dustin destroyed. 2
User Dustin destroyed. 2
User Dustin destroyed. 2
User Dustin destroyed. 2
User Dustin destroyed. 2
User Dustin destroyed. 2
User Dustin destroyed. 2
USER QUEUE: false
INSIDE METHOD: false
AFTER METHOD: false
User Dustin destroyed. 3
User Dustin destroyed. 3
User Dustin destroyed. 3
User Dustin destroyed. 3
User Dustin destroyed. 3
User Dustin destroyed. 3
User Dustin destroyed. 3
User Dustin destroyed. 3
User Dustin destroyed. 3
USER QUEUE: false
INSIDE METHOD: false
AFTER METHOD: false
User Dustin destroyed. 4
User Dustin destroyed. 4
User Dustin destroyed. 4
User Dustin destroyed. 4
User Dustin destroyed. 4
User Dustin destroyed. 4
User Dustin destroyed. 4
User Dustin destroyed. 4
User Dustin destroyed. 4
USER QUEUE: false
INSIDE METHOD: false
AFTER METHOD: false
User Dustin destroyed. 5
User Dustin destroyed. 5
User Dustin destroyed. 5
User Dustin destroyed. 5
User Dustin destroyed. 5
User Dustin destroyed. 5
User Dustin destroyed. 5
User Dustin destroyed. 5
User Dustin destroyed. 5
USER QUEUE: false
INSIDE METHOD: false
AFTER METHOD: false
User Dustin destroyed. 6
User Dustin destroyed. 6
User Dustin destroyed. 6
User Dustin destroyed. 6
User Dustin destroyed. 6
User Dustin destroyed. 6
User Dustin destroyed. 6
User Dustin destroyed. 6
User Dustin destroyed. 6
User Dustin destroyed. 6
Joe
USER QUEUE: false
INSIDE METHOD: false
AFTER METHOD: false
User Dustin pulled from Queue, Game created: Joe
User Already Placed: Dustin with Joe
User Dustin destroyed. 7
User Dustin destroyed. 7
User Dustin destroyed. 7
User Dustin destroyed. 7
User Dustin destroyed. 7
User Dustin destroyed. 7
User Dustin destroyed. 7
User Dustin destroyed. 7
User Dustin destroyed. 7
User Dustin destroyed. 7
INSIDE METHOD: false
INSIDE METHOD: false
USER QUEUE: true
INSIDE METHOD: false
INSIDE METHOD: false
User Dustin destroyed. 9
User Joe destroyed. 9
User Dustin destroyed. 9
User Dustin destroyed. 9
User Dustin destroyed. 9
User Dustin destroyed. 9
INSIDE METHOD: true
INSIDE METHOD: false
USER QUEUE: true
INSIDE METHOD: false
INSIDE METHOD: false
INSIDE METHOD: true
INSIDE METHOD: false
USER QUEUE: true
INSIDE METHOD: false
INSIDE METHOD: false
It really does seem to me like finalize is being called multiple times for the same object.
That number should incremement for every instantiated User, and finalize can only be called once for each User object.
I thought this was impossible?
Any help is appreciated!

Answer 1

Thanks...
I am already thinking of ideas to limit the number of threads.
Unfortunately there are two threads of execution in the servlet handler, one handles requests and the other parses the collection of User objects to check for out of date timestamps, and then eliminates them if they are out of date.
The collection parsing thread is currently a javax.swing.Timer thread (Bad design I know...) so I believe that I can routinely check for timestamps in another way and fix that problem.
Just found out too that Tomcat was throwing me a ConcurrentModificationException as well, which may help explain the slew of mysterious behavior from my servlet!
The Timer thread has to go. I got to think of a better way to routinely weed out User objects from the collection.
Or perhaps, maybe I can attempt to make it thread safe???
Eg. make my User collection volatile?
Any opinions on the best approach are well appreciated.