Home/ Questions/Q 8841781
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T10:48:20+00:00

I have a project that keeps track of state information in over 500k objects,

  • 0

I have a project that keeps track of state information in over 500k objects, the program receives 10k updates/second about these objects, the updates consist of new, update or delete operations.

As part of the program house keeping must be performed on these objects roughly every five minutes, for this purpose I’ve placed them in a DelayQueue implementing the Delayed interface, allowing the blocking functionality of the DelayQueue to control house keeping of these objects.

  • Upon new, an object is placed on the DelayQueue.

  • Upon update, the object is remove()‘d from the DelayQueue, updated and then reinserted at it’s new position dictated by the updated information.

  • Upon delete, the object is remove()‘d from the DelayQueue.

The problem I’m facing is that the remove() method becomes a prohibitively long operation once the queue passes around 450k objects.

The program is multithreaded, one thread handles updates and another the house keeping. Due to the remove() delay, we get nasty locking performance issues, and eventually the update thread buffer’s consumes all of the heap space.

I’ve managed to work around this by creating a DelayedWeakReference (extends WeakReference implements Delayed), which allows me to leave “shadow” objects in the queue until they would expire normally.

This takes the performance issue away, but causes an significant increase in memory requirements. Doing this results in around 5 DelayedWeakReference‘s for every object that actually needs to be in the queue.

Is anyone aware of a DelayQueue with additional tracking that permits fast remove() operations? Or has any suggestions of better ways to handle this without consuming significantly more memory?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    took me some time to think about this,
    but after reading your interesting question for some minutes, here are my ideas:
    A. if you objects have some sort of ID, use it to hash, and actually don’t have one delay queue, but have N delay queues.
    This will reduce the locking factor by N.
    There will be a central data structure,
    holding these N queues. Since N is preconfigured,
    you can create all N queues when the system starts.

    • 0