TimedList - Automatically remove after configurable amount of seconds.

This resource is no longer availabe.

 

I don't see why you need to create an entire background thread for every TimedList - it introduces concurrency for no good reason, wastes a lot of memory (usually 2 MB for the thread's stack) and is not very accurate as the entry count down may fall out of sync with the system clock. Also - isn't it more accurate to call this a TimedSet, as there is no get(index) method or defined order?

Instead, try emulating a DelayQueue, and keep a priority queue of entries that are about to expire. That way, you don't have to scan the entire set for expired items, and you can perform a fast check every time the set is accessed.

I've actually written a HashMap (ProtocolLib) with this feature myself, but it can also be used as a Set:

Code:java

private static ExpireHashMap<String, Boolean> clickers = new ExpireHashMap<String, Boolean>();
 
public static void main(String[] args) throws Exception {
    clickSign();
    clickSign();
    Thread.sleep(3001);
 
    clickSign();
}
 
private static void clickSign() {
    if (clickers.containsKey("player")) {
        System.out.println("Spam clicking is not allowed.");
    } else {
        clickers.put("player", true, 3, TimeUnit.SECONDS);
        System.out.println("Clicked sign.");
    }
}

Of course, you could just use Cooldowns in this case:

Code:java

if (Cooldowns.tryCooldown(player, "Signs", 3000)) {
    // Do what you need to do here. You don't have to set the cooldown when you're done.
} else {
    // Cooldown hasn't expired yet
    player.sendMessage("Spam clicking is not allowed.");
}

That might be the simplest option - and it's just as fast as ExpireHashMap.

 

Ah thanks, I will use ProtocolLib instead.

 

Sure, but you can also copy ExpireHashMap into your project if you don't mind GPL.

Still, I think TimedList could have been salvaged - if you'd replaced the ScheduledExecutorService with just using the standard Bukkit scheduler, the overhead would have been minimal in most cases. Or gone with the delay queue approach.

 

Deleting the thread might not be such a great idea, any code can be useful to someone.