Worker threads and threads that release resources can only have one operation object list at the same time

This premise determines that you must use synchronized blocks to protect the logic of operating this list. This goes without saying;
The remaining question is: How to make the recycling thread take less time to operate the list?

My idea is this: It's very simple. When your recycling thread operates the list, it only does one thing: move the recycled object out of the list and put it in another place (such as another list, "List 2")

If you just "move out", this operation is very fast. I don't know how big your list is, but it can usually be completed instantly;

Then let the working thread operate the list, and the recycling thread slowly handles the recycling work in "List 2" without interfering with each other;

If your object list is really extremely large, then you can design the recycling thread into a "primary-secondary" thread 2-layer structure, in which the main thread starts the sub-thread to remove the list and holds the sub-thread object Application;
The child thread implements the interrupt method and throws a custom exception in the method;

After starting the sub-thread, the main thread sleeps (for a time you think is appropriate). When it wakes up, if it finds that the sub-thread has not ended yet, it calls the interrupt method of the sub-thread

If you simply release it, it shouldn't be a time-consuming operation. Besides, when JVM garbage collection stops the world, it is inevitable that your logic will be blocked. If your quantity is indeed huge, then you can control the number of recycling items each time to make the congestion time as short as possible. Another is to limit the number of object pools in the program, because if you don't limit it, even with the best algorithm, the program will easily get out of control when the number of objects increases.

If the release operation is a very lightweight operation, that is, the time to release each object is very short, you can write a loop in the release thread to determine the current execution time and release one by one, similar to this:

codepublic void run() {
    while(在给定的时间) {
        release(object);
    }
}

I think the people above are right, releasing is a light operation. If you are really worried about blocking time, I have an idea.
Because your object list (assumed to be called ol) is not thread-safe, every operation will lock ol.
Then you can open a separate daemon thread to poll the jvm memory. Once the memory reaches this threshold, it can be considered to be almost used up, and then mark a global change as true.
When your worker thread discovers that this global variable is true, before saving the new object to ol, save the first few objects of ol (1 or 2, not more) because the polling thread does not find other work before the memory is restored. The thread will still release) release and then save the new one.
The daemon thread that polls the memory sets the global variable to false after finding that the memory is lower than the specified threshold, so that the new worker thread will not release the memory.
In this case, you have not introduced any threads that need to lock OL at all, and the blocking rate of your OL is still your original working thread. Since the polling memory thread is a daemon thread, you don't have to worry about graceful termination.

Update

Suddenly I realized that you asked about how to let the thread run for a specified time. . . .
Note the start time before the thread is stuck in the while loop. Calculate the time consumption based on the start time in your loop. You can jump out or sleep when the time you specify is reached.