Maison >interface Web >Questions et réponses frontales >La requête ajax asynchrone est-elle par défaut ?
ajax est une requête asynchrone par défaut ; en ajax, vous pouvez déterminer s'il s'agit d'une requête asynchrone en fonction de la valeur asynchrone. Si la valeur asynchrone est fausse, cela signifie que la requête ajax est synchrone. , cela signifie que la requête ajax est asynchrone et que par défaut la valeur de async est "true", donc ajax est une requête asynchrone par défaut.
L'environnement d'exploitation de cet article : système Windows10, version javascript1.8.5&&html5, ordinateur Dell G3.
ajax est soumis de manière asynchrone par défaut ;
AJAX est divisé en « faux » synchrone et « vrai » asynchrone selon les différentes valeurs asynchrones, et par défaut la valeur asynchrone est vraie ( soumission asynchrone) . L’avantage est que cela peut améliorer l’expérience utilisateur grâce à une actualisation partielle, tout en économisant des ressources et en réduisant la pression sur la base de données.
ajax est une requête asynchrone par défaut, c'est-à-dire async:true, vous pouvez la rendre synchrone en définissant le paramètre asycn:false
$.ajax({ url: 'www.test.com/test/test', type: 'POST', data: {name:"test"} async: false, error: function() { console.log('error'); }, success: function(resp) { console.log('success'); } });
Remarque : si vous avez ce type d'opération. Avant d'appeler ajax, j'ai écrit un flag = false; mais dans le rappel réussi d'ajax, la définition de flag = true et d'autres opérations ne peuvent pas obtenir le résultat souhaité dans l'état asynchrone d'ajax.
Comme ajax est asynchrone par défaut, il est possible d'exécuter l'opération callback flag = true après avoir terminé les opérations suivantes ! !
Connaissances élargies :
Comment AJAX implémente-t-il les requêtes synchrones ?
Les requêtes Ajax sont divisées en requêtes synchrones et requêtes asynchrones, mais celles par défaut sont des requêtes asynchrones. Alors, lorsque nous voulons utiliser ajax pour demander de manière synchrone, comment devons-nous implémenter cette requête synchrone ? L'article suivant vous présentera l'implémentation de la demande de synchronisation ajax. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.
Tout d'abord, nous devons savoir que la synchronisation est un seul thread et que le code est exécuté dans l'ordre. Lorsque le code js est chargé dans la requête ajax synchrone actuelle, tous les autres codes de la page cessent de se charger et la page est chargée. dans un état d'animation suspendue jusqu'à la demande. Une fois l'exécution terminée, d'autres demandes seront exécutées.
Deuxièmement, il faut savoir que ajax est divisé en deux méthodes de requête : synchrone et asynchrone selon la valeur de async. Lorsque la valeur de async est vraie, c'est la méthode de requête asynchrone. Au contraire, lorsque la valeur de async. est faux, c'est la méthode de requête synchrone. Donc, pour implémenter la requête de synchronisation ajax, il vous suffit de définir la valeur de async sur false.
$.ajax( type:“POST”/“GET” url:"", data:{}, dataType:"json", async:false, //同步 success:function(response){ } );
Quelle est la différence entre les requêtes Ajax synchrones et asynchrones et quels sont les scénarios d'utilisation ?
Compréhension 1 :
AJAX est divisé en deux méthodes d'exécution : synchrone (async = false) et asynchrone (async = true) selon la valeur de async ; Distinguons la différence entre synchronisation et asynchronisme :
Asynchrone : En mode asynchrone, après avoir utilisé AJAX pour envoyer la requête, il peut y avoir du code qui doit être exécuté. À l'heure actuelle, le serveur n'a peut-être pas répondu à notre demande pour diverses raisons, mais comme nous utilisons l'exécution asynchrone, le code restant dans toutes les fonctions contenant le code de requête AJAX continuera à s'exécuter. Si nous transmettons le résultat de la requête à une autre fonction JS pour traitement, ce sera comme si deux threads s'exécutaient en même temps.
Synchronisation : en mode synchrone, après avoir utilisé AJAX pour envoyer la requête, il reste encore du code qui doit être exécuté plus tard. Nous transmettons également la réponse du serveur à une autre fonction JS pour traitement, mais la situation d'exécution du code à ce moment-là. est : sur le serveur Lorsqu'il n'y a pas de réponse ou que la fonction JS qui gère le résultat de la réponse n'a pas été traitée et renvoyée, le code restant de la fonction contenant le code de la requête ne peut pas être exécuté. Tout comme un seul thread, il entre dans l'état de blocage après l'envoi de la requête, et le code restant ne continuera pas à s'exécuter jusqu'à ce qu'il touche l'état de blocage.
Comment choisir le mode synchrone ou asynchrone ? Pour répondre à cette question, nous pouvons y répondre à travers les questions possibles suivantes :
Après l'envoi de la requête AJAX, nous devons toujours continuer à traiter les résultats de la réponse du serveur si nous utilisons le mode de requête asynchrone et ne confions pas le traitement de. les résultats, traités par une autre fonction JS. À ce stade, cette situation peut se produire : la réponse à la requête asynchrone n'est pas encore arrivée et la fonction a fini d'exécuter l'instruction return, ce qui fera que le résultat du retour sera une chaîne vide.
Compréhension 2 :Synchronisation : envoyer une demande, attendre le retour, puis envoyer la prochaine demande
Asynchrone : envoyer une demande, n'attendre pas le retour et pouvoir envoyer la prochaine demande à tout moment
La synchronisation peut éviter les blocages. Le verrouillage, l'apparition de lectures de données sales, est généralement utilisé lors du partage d'une certaine ressource. Si tout le monde dispose des autorisations de modification et modifie un fichier en même temps, il est possible pour une personne de lire le contenu qu'une autre. la personne a supprimé et une erreur se produira. Synchronisation Il sera modifié dans l'ordre.
L'asynchrone peut améliorer l'efficacité. De nos jours, les processeurs sont dual-core ou quad-core. Si vous traitez de manière asynchrone, vous pouvez effectuer plusieurs tâches en même temps. Bien sûr, vous devez vous assurer qu'elles peuvent être traitées simultanément.
La plus grande différence entre synchrone et asynchrone est. Il faut attendre, ce n’est pas le cas.
L'envoi de messages texte, par exemple, est un exemple asynchrone. L'initiateur ne se soucie pas du statut du destinataire. Il n'est pas nécessaire d'attendre les informations de retour du récepteur et la transmission suivante peut être effectuée.
Le téléphone est un exemple de synchronisation. L'initiateur doit attendre le destinataire et la communication ne démarre que lorsque l'appel est connecté. Vous devez attendre les informations de retour du récepteur
Et les problèmes de synchronisation dont nous discutons souvent se produisent principalement lors de problèmes de partage de données dans des environnements multithread. Autrement dit, lorsque plusieurs threads doivent accéder à la même ressource, ils doivent être dans un certain ordre pour garantir que la ressource ne peut être accédée que par un seul thread à un moment précis. Si le mode asynchrone est utilisé, les résultats d'exécution du programme le seront. être imprévisible. Par conséquent, dans ce cas, les données doivent être synchronisées, c'est-à-dire qu'un seul processus peut accéder à la ressource et les autres threads doivent attendre.
Les mécanismes pour réaliser la synchronisation incluent principalement les sections critiques, les mutex, les sémaphores et les événements.
Section critique : accédez à des ressources publiques ou à un morceau de code via la sérialisation de multi-threads, rapide et adaptée au contrôle de l'accès aux données. Un seul thread est autorisé à accéder aux ressources partagées à tout moment. Si plusieurs threads tentent d'accéder aux ressources publiques, après l'entrée d'un thread, les autres threads essayant d'accéder aux ressources publiques seront suspendus et attendront d'entrer dans la section critique après la sortie du thread. et la section critique est libérée, d'autres threads peuvent la préempter.
Mutex : adopte un mécanisme d'objet mutuellement exclusif. Seuls les threads possédant des objets mutuellement exclusifs sont autorisés à accéder aux ressources publiques. Comme il n'existe qu'un seul objet mutuellement exclusif, il est garanti que les ressources publiques ne seront pas accessibles par plusieurs threads en même temps. Mutex peut non seulement réaliser le partage sécurisé des ressources publiques d'une même application, mais également réaliser que le partage sécurisé des ressources publiques de différentes applications est plus compliqué que la section critique. Parce que l'utilisation de l'exclusion mutuelle peut non seulement permettre un partage sécurisé des ressources entre différents threads d'une même application, mais également réaliser un partage sécurisé des ressources entre les threads de différentes applications.
Sémaphore : il permet à plusieurs threads d'accéder à la même ressource en même temps, mais il doit limiter le nombre maximum de threads pouvant accéder à cette ressource en même temps. La façon dont l'objet sémaphore synchronise les threads est différente des méthodes précédentes. Le signal permet à plusieurs threads d'utiliser des ressources partagées en même temps, ce qui est identique à l'opération PV dans le système d'exploitation. Il indique le nombre maximum de threads pouvant accéder aux ressources partagées en même temps. Il permet à plusieurs threads d'accéder à la même ressource en même temps, mais doit limiter le nombre maximum de threads pouvant accéder à cette ressource en même temps.
Événements : maintenez la synchronisation des threads grâce aux opérations de notification et facilitez également la comparaison des priorités de plusieurs threads.
【Recommandation de didacticiel connexe : Tutoriel vidéo AJAX】
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!