Questions d'entretien Java multithreading et simultanée (1 à 3 questions, avec réponses)

1. DelayQueue retarde la file d'attente de blocage illimitée

Lorsque nous parlons de l'utilisation et du principe de DelayQueue, nous introduisons d'abord DelayQueue, DelayQueue est un illimité. file d'attente de blocage dont les éléments ne peuvent être extraits qu'à l'expiration du délai. La tête de file d’attente est l’élément Delayed qui sera stocké le plus longtemps après l’expiration du délai. (Étude recommandée : questions d'entretien Java)

La file d'attente de blocage DelayQueue est également souvent utilisée dans le développement de notre système, par exemple : la conception du système de cache, les objets dans le cache, dépassent le le temps d'inactivité doit être déplacé du cache ; le système de planification des tâches peut saisir avec précision le temps d'exécution de la tâche. Nous devrons peut-être traiter de nombreuses données urgentes via des threads.

Si nous utilisons des threads ordinaires, nous devons parcourir tous les objets et vérifier un par un pour voir si les données ont expiré. Tout d'abord, l'efficacité d'exécution ne sera pas trop élevée. Deuxièmement, le style de conception. Cela affecte également grandement l'exactitude des données. Une tâche qui doit être exécutée à 12h00 peut ne pas être exécutée avant 12h01, ce qui présente de plus grands inconvénients pour les systèmes nécessitant des données élevées. À partir de là, nous pouvons utiliser DelayQueue.

Ce qui suit donnera une introduction à DelayQueue et donnera un exemple. Et fournissez une implémentation de l’interface retardée et de l’exemple de code. DelayQueue est un BlockingQueue dont le paramètre spécialisé est Delayed.

(Étudiants qui ne connaissent pas BlockingQueue, veuillez d'abord vous renseigner sur BlockingQueue, puis lire cet article) Delayed étend l'interface Comparable La référence de comparaison est la valeur du temps de retard de getDelay, la classe d'implémentation. de l’interface Delayed, doit être une valeur fixe (finale). DelayQueue est implémenté en interne à l'aide de PriorityQueue.

DelayQueue=BlockingQueue+PriorityQueue+Delayed

Les éléments clés de DelayQueue sont BlockingQueue, PriorityQueue et Delayed. On peut dire que DelayQueue est un BlockingQueue implémenté à l'aide d'une file d'attente prioritaire (PriorityQueue). La valeur de base de comparaison de la file d'attente prioritaire est le temps.

Leurs définitions de base sont les suivantes

public interface Comparable<T> {
    public int compareTo(T o);
}
public interface Delayed extends Comparable<Delayed> {
    long getDelay(TimeUnit unit);
}
public class DelayQueue<E extends Delayed> implements BlockingQueue<E> {
    private final PriorityQueue<E> q = new PriorityQueue<E>();
}

L'implémentation interne de DelayQueue utilise une file d'attente prioritaire. Lorsque la méthode d'offre de DelayQueue est appelée, l'objet Delayed est ajouté à la file d'attente prioritaire q. Comme suit :

public boolean offer(E e) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        E first = q.peek();
        q.offer(e);
        if (first == null || e.compareTo(first) < 0)
            available.signalAll();
        return true;
    } finally {
        lock.unlock();
    }
}

La méthode take de DelayQueue supprime le premier de la file d'attente prioritaire q (peek). Si le seuil de délai n'est pas atteint, le traitement d'attente est effectué. Comme suit :

public E take() throws InterruptedException {
    final ReentrantLock lock = this.lock;
    lock.lockInterruptibly();
    try {
        for (; ; ) {
            E first = q.peek();
            if (first == null) {
                available.await();
            } else {
                long delay = first.getDelay(TimeUnit.NANOSECONDS);
                if (delay > 0) {
                    long tl = available.awaitNanos(delay);
                } else {
                    E x = q.poll();
                    assert x != null;
                    if (q.size() != 0)
                        available.signalAll(); //wake up other takers return x;
                }
            }
        }
    } finally {
        lock.unlock();
    }
}

Application d'instance DelayQueue

Ps : Afin d'avoir un comportement d'appel, les éléments stockés dans DelayDeque doivent hériter de l'interface Delayed. L'interface Delayed fait de l'objet un objet retardé, ce qui donne à l'objet stocké dans la classe DelayQueue une date d'activation. Cette interface applique les deux méthodes suivantes.

Ce qui suit utilisera Delay pour implémenter un cache. Il comprend trois classes : Pair, DelayItem, Cache

Classe Pair :

public class Pair<K, V> {
    public K first;
    public V second;
    public Pair() {
    }
    public Pair(K first, V second) {
        this.first = first;
        this.second = second;
    }
}

Ce qui suit est l'implémentation de l'interface Delay :

import java.util.concurrent.Delayed;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;
public class DelayItem<T> implements Delayed {
    /**
     * Base of nanosecond timings， to avoid wrapping
     */
    private static final long NANO_ORIGIN = System.nanoTime();
    /**
     * Returns nanosecond time offset by origin
     */
    final static long now() {
        return System.nanoTime() - NANO_ORIGIN;
    }
    /**
     * Sequence number to break scheduling ties， and in turn to guarantee FIFO order among tied
     * entries.
     */
    private static final AtomicLong sequencer = new AtomicLong(0);
    /**
     * Sequence number to break ties FIFO
     */
    private final long sequenceNumber;
    /**
     * The time the task is enabled to execute in nanoTime units
     */
    private final long time;
    private final T item;
    public DelayItem(T submit， long timeout) {
        this.time = now() + timeout;
        this.item = submit;
        this.sequenceNumber = sequencer.getAndIncrement();
    }
    public T getItem() {
        return this.item;
    }
    public long getDelay(TimeUnit unit) {
        long d = unit.convert(time - now()， TimeUnit.NANOSECONDS); return d;
    }
    public int compareTo(Delayed other) {
        if (other == this) // compare zero ONLY if same object return 0;
            if (other instanceof DelayItem) {
                DelayItem x = (DelayItem) other;
                long diff = time - x.time;
                if (diff < 0) return -1;
                else if (diff > 0) return 1;
                else if (sequenceNumber < x.sequenceNumber) return -1;
                else
                    return 1;
            }
        long d = (getDelay(TimeUnit.NANOSECONDS) - other.getDelay(TimeUnit.NANOSECONDS));
        return (d == 0) ?0 :((d < 0) ?-1 :1);
    }
}

Ce qui suit est l'implémentation de Cache, y compris les méthodes put et get

import javafx.util.Pair;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;
import java.util.concurrent.DelayQueue;
import java.util.concurrent.TimeUnit;
import java.util.logging.Level;
import java.util.logging.Logger;
public class Cache<K, V> {
    private static final Logger LOG = Logger.getLogger(Cache.class.getName());
    private ConcurrentMap<K, V> cacheObjMap = new ConcurrentHashMap<K, V>();
    private DelayQueue<DelayItem<Pair<K, V>>> q = new DelayQueue<DelayItem<Pair<K, V>>>();
    private Thread daemonThread;
    public Cache() {
        Runnable daemonTask = new Runnable() {
            public void run() {
                daemonCheck();
            }
        };
        daemonThread = new Thread(daemonTask);
        daemonThread.setDaemon(true);
        daemonThread.setName("Cache Daemon");
        daemonThread.start();
    }
    private void daemonCheck() {
        if (LOG.isLoggable(Level.INFO)) LOG.info("cache service started.");
        for (; ; ) {
            try {
                DelayItem<Pair<K, V>> delayItem = q.take();
                if (delayItem != null) {
                    // 超时对象处理
                    Pair<K, V> pair = delayItem.getItem();
                    cacheObjMap.remove(pair.first, pair.second); // compare and remove
                }
            } catch (InterruptedException e) {
                if (LOG.isLoggable(Level.SEVERE)) LOG.log(Level.SEVERE, e.getMessage(), e);
                break;
            }
        }
        if (LOG.isLoggable(Level.INFO)) LOG.info("cache service stopped.");
    }
    // 添加缓存对象
    public void put(K key, V value, long time, TimeUnit unit) {
        V oldValue = cacheObjMap.put(key, value);
        if (oldValue != null) q.remove(key);
        long nanoTime = TimeUnit.NANOSECONDS.convert(time, unit);
        q.put(new DelayItem<Pair<K, V>>(new Pair<K, V>(key, value), nanoTime));
    }
    public V get(K key) {
        return cacheObjMap.get(key);
    }
}

Testez la méthode principale :

// 测试入口函数
public static void main(String[] args) throws Exception {
    Cache<Integer, String> cache = new Cache<Integer, String>();
    cache.put(1, "aaaa", 3, TimeUnit.SECONDS);
    Thread.sleep(1000 * 2);
    {
        String str = cache.get(1);
        System.out.println(str);
    }
    Thread.sleep(1000 * 2);
    {
        String str = cache.get(1);
        System.out.println(str);
    }
}

Le résultat de sortie est :

aaaa
null

Nous voyons le résultat ci-dessus si le délai est dépassé, les données dans le cache seront automatiquement perdues et le résultat sera nul.

2. File d'attente simultanée (Collection) - file d'attente non bloquante

File d'attente non bloquante

Tout d'abord, il faut le comprendre simplement Ensuite, qu'est-ce qu'une file d'attente non bloquante :

Contrairement à la file d'attente bloquante, l'exécution de la file d'attente non bloquante ne sera pas bloquée, qu'il s'agisse de la sortie de file d'attente des consommateurs ou du regroupement de producteurs. Sous le capot, les files d'attente non bloquantes utilisent CAS (comparer et échanger) pour réaliser une exécution de thread non bloquante.

Opérations simples pour les files d'attente non bloquantes

Tout comme les files d'attente bloquantes, les méthodes courantes dans les files d'attente non bloquantes sont la mise en file d'attente et la mise en file d'attente.

offer() : Une méthode héritée de l'interface Queue, qui implémente l'opération d'entrée dans la file d'attente et n'empêche pas l'exécution du thread si l'insertion est réussie, elle renvoie true ;

poll() : déplacez le pointeur du nœud principal, renvoie l'élément du nœud principal et retirez l'élément du nœud principal ; si la file d'attente est vide, renvoie null

peek() : déplacez le pointeur du nœud principal ; , renvoie l'élément du nœud principal, l'élément du nœud principal ne sera pas retiré de la file d'attente ; si la file d'attente est vide, null sera renvoyé

3. 🎜>Nous devons d'abord comprendre le verrouillage pessimiste et le verrouillage optimiste

Verrouillage pessimiste : supposons que l'environnement de concurrence est pessimiste. Si un conflit de concurrence se produit, la cohérence sera détruite, les conflits doivent donc être complètement. interdit par des serrures exclusives. Il existe une métaphore classique : « Si vous ne verrouillez pas la porte, alors le fauteur de troubles entrera par effraction et fera des dégâts », donc « vous ne pouvez ouvrir la porte et laisser entrer qu'une seule personne à la fois, afin de garder un oeil sur lui."

Verrouillage optimiste : on suppose que l'environnement de concurrence est optimiste, c'est-à-dire que même s'il y aura des conflits de concurrence, les conflits peuvent être découverts et ne causeront pas de dommages. Par conséquent, aucune protection ne peut être ajoutée et la décision de donner. une nouvelle tentative sera effectuée une fois les conflits de concurrence découverts. Une analogie est : « Si vous ne verrouillez pas la porte, même si les fauteurs de troubles entreront par effraction, ils sauront s'ils veulent vous détruire. Par conséquent, « vous pouvez simplement laisser entrer tout le monde et attendre de découvrir qu'ils sont là. » vouloir détruire." Prendre une décision".

On pense généralement que les performances du verrouillage optimiste sont supérieures à celles du verrouillage pessimiste, en particulier dans certains scénarios complexes. Cela est principalement dû au fait que les verrous pessimistes protégeront également certaines opérations qui ne causeront pas de dommages lors du verrouillage ; alors que la concurrence pour les verrous optimistes ne se produit qu'aux plus petits conflits de concurrence. Si nous utilisons les verrous pessimistes pour le comprendre, c'est le « verrouillage ». La granularité est la plus petite. ». Cependant, la conception des verrous optimistes est souvent plus complexe, c’est pourquoi les verrous pessimistes sont souvent utilisés dans des scénarios complexes. Assurez-vous d’abord de l’exactitude, puis recherchez la performance si nécessaire.

La mise en œuvre du verrouillage optimiste nécessite souvent un support matériel. La plupart des processeurs implémentent une instruction CAS pour implémenter la sémantique de "Compare And Swap" (swap signifie ici "swap in", c'est-à-dire définir), formant un verrou optimiste de base. CAS contient 3 opérandes :

L'emplacement mémoire à lire et écrire V

La valeur à comparer A

La nouvelle valeur à écrire B

CAS mettra à jour atomiquement la valeur de la position V avec la nouvelle valeur B si et seulement si la valeur de la position V est égale à A sinon aucune opération ne sera effectuée. Que la valeur de la position V soit égale ou non à A, la valeur originale de V sera renvoyée. Un fait intéressant est que « utiliser CAS pour contrôler la concurrence » n’équivaut pas à « utiliser le verrouillage optimiste ». CAS n'est qu'un moyen d'obtenir à la fois un verrouillage optimiste et un verrouillage pessimiste. L'optimisme et le pessimisme ne sont que des stratégies de contrôle de concurrence.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!