Uso del mondo reale di DelayQueue [chiuso]

Recentemente ho usato una coda di ritardo per la limitazione della velocità.

Per un limite di eventi X al secondo, inserisci ciascun evento in una coda di ritardo con un ritardo di 1 secondo.

Se ci sono eventi X su delayQueue, take () dalla coda (che blocca fino ad almeno 1 scadenza). In questo modo permetti un'esplosione a breve termine, senza superare i limiti a lungo termine.

Questa classe è perfetta per un thread che desidera elaborare più eventi in ritardo nell'ordine corretto.

Supponiamo, ad esempio, di disporre di un display con 100 luci lampeggianti e che tutte le luci lampeggino a frequenze diverse e non correlate. Si potrebbe avere una discussione per ogni luce, oppure si potrebbe avere una coordinata di filo tutte usando questa classe. Funzionerebbe qualcosa del genere:

• ha una classe Light con una velocità flash
• crea un'implementazione dell'interfaccia Delayed che punta alla luce, ad esempio LightFlash
• crea il DelayQueue e aggiungi un nuovo LightFlash per ogni luce, con il ritardo impostato appropriato per la velocità del flash della luce
• ciclo:
  • ottieni un evento con DelayQueue :: prendere () .
  • attiva / disattiva la luce
  • aggiungi un nuovo evento alla coda per il prossimo flash della luce con DelayQueue :: mettere (E) .

DelayQueue si occupa di far elaborare l'evento successivo.

Due esempi del mondo reale a cui riesco a pensare:

• Un server (senza multithreading) che deve eseguire determinate azioni temporizzate, ad es. collegamento ping su ciascuna connessione.
• Implementazione di un browser abilitato per javascript, che deve gestire il numero arbitrario di eventi temporizzati creati con setInterval () e setTimeout () . Oh, e GIF animate.

DelayQueue è probabilmente implementato come coda di priorità , che in genere è meglio implementata come heap .

l'utilizzo principale sarebbe costituito da timer di attività come le classi Timer

se si può rendere il ritardo indipendente dall'orologio di sistema (che credo si possa, non è sicuro) si può usarlo per eventi di gioco come "dopo 5 tick andare a X" (altrimenti il clock jitter wold lo rende inaffidabile)

Si noti che i ritardi sono associati agli elementi che vanno in coda piuttosto che alla coda stessa. Alcuni oggetti che entrano in coda potrebbero avere un ritardo pari a zero, mentre alcuni possono avere un ritardo molto più lungo:

link

Con questo in mente, posso pensare ad alcuni casi d'uso, anche se probabilmente sarebbero fragili e un po 'di odore di codice per quanto riguarda il flusso di messaggi. Userei alternative a tutti tranne che in situazioni specifiche:

1) Flusso di controllo: sappiamo che un ordine impiega 60 secondi per essere elaborato, quindi non leggere l'ordine successivo fuori dalla coda finché l'oggetto non è rimasto lì per almeno 60 secondi.

2) Flusso di messaggi - Un sistema altamente asincrono in cui inviamo richieste a 2 o 3 servizi esterni e quindi rilasciamo l'attività successiva per elaborare l'ordine N secondi più tardi una volta che sappiamo che il primo lotto di lavori avrà almeno un possibilità di completamento.

3) Lancio dei messaggi - forse gli ordini di un certo tipo sono scoppiati, quindi non processiamo gli ordini ricevuti negli ultimi N secondi in modo che possiamo vedere se ordini simili arrivano poco dopo che possono essere processati come un batch alla prossima esecuzione .

4) Priorità messaggi: messaggi diversi o clienti diversi potrebbero ottenere una qualità del servizio leggermente più alta con un ritardo inferiore o pari a zero.

In alcuni casi, gli oggetti posizionati su una coda dovrebbero trovarsi su quella coda per un certo periodo di tempo prima che siano pronti per essere rimossi dalla coda. Qui è dove si utilizza la classe java.util.concurrent.DelayQueue, che implementa l'interfaccia BlockingQueue. Il DelayQueue richiede che gli oggetti di coda siano residenti in coda per un intervallo di tempo specificato.

Per esempio di utilizzo del mondo reale vedi Minding the Queue articolo sul sito devx

...The real world example that I thought of to illustrate this (which might make you hungry) involves muffins. Well, Muffin objects (as we are talking Java—no coffee pun intended). Suppose you have a DelayQueue upon which you place Muffin objects... The getDelay method, in essence, states how much time is left for the object to be kept in the DelayQueue. When the number returned by this method becomes zero or less than zero, the object is ready (or in this example, baked) and allowed to be dequeued...

Since you don't really want to eat a Muffin that's not fully cooked, place the Muffin on the DelayQueue for the recommended cooking time...