Concurrence élevée
C'est l'un des facteurs dont il faut tenir compte dans la conception de l'architecture du système distribué Internet. Il s'agit généralement de garantir que le système peut traiter simultanément des demandes massives en parallèle.
Synchrone et asynchrone
Synchrone: envoyez une demande, attendez le retour, puis envoyez la demande suivante. Soumettez la demande -> attendez que le serveur traite -> retour après traitement, le navigateur client ne peut rien faire pendant cette période
Asynchrone: envoyez une demande sans attendre le retour, et vous pouvez envoyer la demande suivante à tout moment. Soumettre la demande -> traitement du serveur (le navigateur peut encore faire d'autres choses à ce moment) -> traitement terminé 
1233.
Comme vous pouvez le voir sur la figure ci-dessus, en suivant la trajectoire en temps réel, il est exécuté de manière synchrone étape par étape. En asynchrone , lorsqu'un processus asynchrone est appelé Après son envoi, l'appelant ne peut pas obtenir le résultat immédiatement. En fait, un thread est lancé pour exécuter cette partie du contenu. Une fois le thread traité, l'appelant est invité à le traiter via l'état , notification et rappel.
Concurrence et parallélisme
11 Sur un
processeur monocœur (processeur unique), il ne peut y avoir que concurrence mais pas de parallélisme. Le parallélisme existe dans les systèmes multiprocesseurs, et la concurrence peut exister dans les systèmes à processeur unique et multiprocesseur. La concurrence peut exister dans les systèmes à processeur unique car la concurrence est une illusion de parallélisme. Le parallélisme nécessite que plusieurs programmes puissent être exécutés simultanément Opération, et la concurrence oblige simplement le programme à faire semblant d'effectuer plusieurs opérations en même temps (chaque petite tranche de temps effectue une opération, plusieurs opérations commutent rapidement l'exécution
Section critique
La
section critique 111 est utilisée pour représenter une ressource commune ou des données partagées, qui peuvent être utilisées par plusieurs threads, mais à la fois, un seul thread peut l'utiliser. Une fois la ressource critique occupée, d'autres threads veulent utiliser cette ressource. Vous devez attendre.
C'est là que nous devons souvent ajouter des verrous dans la programmation, tels que le mot clé Synchronized ou l'interface Lock.
Bloquant et non bloquant
Le blocage et le non-blocage sont généralement utilisés pour décrire l'interaction entre plusieurs threads. Par exemple, si un thread occupe une ressource de région critique, tous les autres threads qui ont besoin de cette ressource doivent attendre et attendre dans cette région critique. Cela entraînera le thread à accrocher, cette situation est bloquante. Si le thread occupant la ressource n'a pas voulu libérer la ressource, tous les autres threads bloqués sur cette section critique ne peuvent pas fonctionner.
Le non-blocage permet à plusieurs threads d'entrer dans la section critique en même temps.
Impasse, famine, vivelock
Blocage: fait référence à un phénomène dans lequel deux ou plusieurs processus (ou threads) sont en concurrence pour les ressources et attendent l'un l'autre pendant l'exécution. S'il n'y a pas de force externe, ils ne pourront pas avancer. À ce stade, on dit que le système est dans un état de blocage ou que le système est dans une impasse. Ces processus qui attendent toujours les uns les autres sont appelés processus de blocage.
Condition mutuellement exclusive: l'accès des threads aux ressources est exclusif. Si une paire de threads occupe une certaine ressource, les autres threads doivent être en état d'attente jusqu'à ce que la ressource soit libérée.
Conditions de demande et de maintien: le thread T1 a au moins conservé une ressource R1 occupée, mais il fait une demande pour une autre ressource R2. À ce stade, la ressource R2 est occupée par d'autres threads T2, le thread T1 doit donc également attendre, mais il est seule La ressource retenue R1 n'est pas libérée.
Conditions de non-privation: les ressources qu'un thread a acquises ne peuvent pas être privées par d'autres threads avant d'être épuisées, et ne peuvent être libérées par elles-mêmes qu'après épuisement.
Condition d'attente de boucle: Lorsqu'un blocage survient, il doit y avoir une "chaîne circulaire ressource-processus", à savoir: {p0, p1, p2, ... pn}, le processus p0 (ou thread) attend les ressources occupées par p1 , et p1 attend les ressources p2 occupées, pn attend les ressources occupées par p0. (La compréhension la plus intuitive est que p0 attend les ressources occupées par p1, et p1 attend les ressources occupées par p0, donc les deux processus attendent l'un l'autre
Livelock : fait référence au thread T1 qui peut utiliser des ressources, mais il est très poli de laisser les autres threads utiliser les ressources en premier, et le thread T2 peut également utiliser des ressources, mais il est doux et permet aux autres threads d'utiliser les ressources en premier. Alors laissez-moi, je vous laisse, les deux derniers threads ne peuvent pas utiliser de ressources.
J'ai rencontré une fille dans la rue, elle marchait dans la direction opposée de vous, et quand elle vous a rencontré de front, vous vouliez tous les deux vous laisser passer. Vous vous déplacez vers la gauche, et elle se déplace également vers la gauche, les deux ne peuvent toujours pas passer. Lorsque vous vous déplacez vers la droite, elle se déplace vers la droite et le cycle continue.
Starvation : Se réfère à si le thread T1 occupe la ressource R, le thread T2 demande à nouveau de bloquer R, donc T2 attend. T3 demande également la ressource R. Lorsque T1 libère le blocage sur R, le système approuve d'abord la demande de T3 et T2 est toujours en attente. Puis T4 demande à nouveau de bloquer R. Lorsque T3 libère le blocus sur R, le système approuve à nouveau la demande de T4 ... et T2 peut attendre indéfiniment.
Il y a deux routes, A et B, qui sont pleines de véhicules. La route A est bloquée le plus longtemps, tandis que la route B est relativement bloquée pendant un temps plus court. À ce stade, la route en face a été dégagée et la circulation la police a signalé la route B selon le principe de la meilleure répartition. Les véhicules sont passés les premiers, puis les uns après les autres sur la route B. La plus longue file d'attente sur la route A n'a pas été passée. Vous ne pouvez qu'attendre que la police de la circulation donne des instructions pour laisser la route Un passage lorsqu'il n'y a pas de trafic sur la route
B.Ceci est ReentrantLock montre le mécanisme de verrouillage injuste fourni dans la serrure (bien sûr, ReentrantLock
fournit également un mécanisme de verrouillage équitable, et l'utilisateur décide de la stratégie de verrouillage à utiliser en fonction de l'utilisation spécifique Un verrouillage injuste peut améliorer le débit, mais il est inévitable Provoquera la famine de certains threads.
Niveau de concurrence
Divisé en bloquant et non bloquant (le non-blocage est divisé en sans obstacle, sans verrou, sans attente)
bloquer
Lorsqu'un thread entre dans la section critique, les autres threads doivent attendre
Sans barrière
L'accessibilité est l'une des plus faibles planification non bloquante.
Accès gratuit à la zone critique. Lorsqu'il n'y a
pas de concurrence, l'opération
est terminée en une étape limitée. En cas de concurrence, les données sont annulées
Par rapport à l'ordonnancement non bloquant, l'ordonnancement bloquant est une stratégie pessimiste. On pensera que la modification des données ensemble est susceptible de changer les données. La planification non bloquante est une stratégie optimiste. Elle estime que si vous modifiez les données, elle risque de ne pas changer les données. Mais c'est une stratégie d'entrée indulgente et de sortie stricte. Lorsqu'il constate qu'un processus a un conflit de données dans la zone critique et qu'un conflit se produit, la méthode de planification sans barrières annulera ces données.
Dans cette méthode de planification sans obstacle, tous les threads sont équivalents à prendre un instantané du système actuel. Ils essaieront toujours de prendre les instantanés jusqu'à ce qu'ils soient valides.
aucun verrou
Il est sans obstacle. Il est
garanti qu'un thread peut gagner.
Comparé à un thread sans obstacle, l'accessibilité ne garantit pas que l'opération sera terminée en cas de concurrence, car s'il constate que chaque opération sera en conflit, il continuera d'essayer . Si les threads de la section critique interfèrent les uns avec les autres, tous les threads seront bloqués dans la section critique et les performances du système auront un impact important.
Le lock-free ajoute une nouvelle condition pour s'assurer qu'un thread peut gagner chaque compétition, ce qui résout le problème d'accessibilité. Au moins pour s'assurer que tous les threads sont exécutés correctement.
Le code suivant est un code de calcul sans verrouillage typique en Java
while (!atomicVar.compareAndSet(localVar, localVar+1)) {
localVar = atomicVar.get();
}
Pas d'attente
Sans verrouillage,
tous les threads doivent être terminés en un nombre limité d'étapes
sans famine
Le principe de la non-attente est basé sur le mode sans verrouillage. Le mode sans verrouillage garantit uniquement que la section critique doit être entrée et sortie. Cependant, si la priorité entrante est élevée, certains threads avec une priorité faible dans la section critique peuvent se produire. ne peut pas sortir de la zone critique. Ensuite, aucune attente ne résout ce problème, cela garantit que tous les threads doivent être terminés en une étape limitée, naturellement il n'y a pas de faim.
Aucune attente est le plus haut niveau de parallélisme, qui peut amener le système à atteindre son état optimal. Un cas typique de non attente: il n'y a qu'un thread de lecture et pas de thread d'écriture, donc cela ne doit pas être d'attente. S'il existe à la fois un thread de lecture et un thread d'écriture, et avant chaque thread d'écriture, une copie des données est copiée, puis la copie est modifiée à la place des données d'origine. La copie étant modifiée, il n'y a pas de conflit, alors le processus de modification est également Pas d'attente. La dernière chose qui doit être synchronisée est de remplacer les données d'origine par les données écrites. Étant donné que l'exigence de l'absence d'attente est relativement élevée et qu'elle est plus difficile à mettre en œuvre, l'utilisation du système sans verrouillage sera plus largement utilisée.
Deux lois importantes sur le parallélisme
Les deux lois sont liées à l'accélération
Loi d'Amdahl
** Loi d'Amdahl (loi d'Amdahl): définit la formule de calcul et la limite supérieure théorique du rapport d'accélération après la mise en parallèle du système série (rapport d'accélération = temps système avant optimisation / temps système après optimisation)
**
un programme (ou un algorithme) peut être divisé en deux parties selon qu'il peut être parallélisé:
La pièce qui
peut être parallélisée La pièce qui ne peut pas être parallélisée
Supposons qu'un programme traite les fichiers sur le disque. Une petite partie de ce programme est utilisée pour analyser les chemins et créer des répertoires de fichiers en mémoire. Après cela, chaque fichier est remis à un thread distinct pour traitement. Le chemin d’analyse et la création du répertoire de fichiers ne peuvent pas être parallélisés, mais le processus de traitement des fichiers le peut.
L'augmentation du nombre de processeurs CPU n'a pas nécessairement un effet efficace. Augmentez la proportion de modules qui peuvent être parallélisés dans le système et augmentez raisonnablement le nombre de processeurs parallèles pour obtenir l'accélération maximale avec un investissement minimum.
Loi Gustafson
La loi de Gustafson (Gustafson):. Expliquer la relation entre le nombre de processeurs, le ratio série et accélération 
11
Tant qu'il y a parallélisation suffisant, le rapport accélération est proportionnelle au nombre de processeurs.
Apprenez la programmation Java sans fondement, je recommande de rejoindre mon coin d'apprentissage Java .