Java

Quelle est la différence entre Spring et Spring Boot?

mises en œuvre - Logique de connexion entre utilisateurs et producteurs - Les clés de messages peuvent être dupliquées - Erreur dans la synchronisation du décalage des consommateurs avec les messages - Pas d'ambiance pour le producteur - Absence d'exécution pour plusieurs brokers - Le groupe de consommateurs est défini de manière rigide

Quelle a été la dernière tâche qui t'a semblé intéressante, difficile, mémorable?

Quelle carte utiliseriez-vous si je lis souvent mais insère rarement des données?

Quelle est la principale problématique de cette implémentation - Utilisation inefficace du pool fixe de threads - Problèmes d'interaction avec les ressources partagées - L'inclusion incorrecte du verrouillage peut conduire à une situation de blocage. - Niveau de synchronisation incorrect - Pas de vérifications de tous les threads avant le résultat - Pas de constructeur explicite Code: import java.util.concurrent.locks.ReentrantLock; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; class RecyclingBinCounter { private int binCount; private final ReentrantLock lock = new ReentrantLock(); public void incrementBins() { lock.lock(); try { binCount++; } finally { lock.unlock(); } } public int getBinCount() { return binCount; } } class RecyclingManager { public static void main(String[] args) { RecyclingBinCounter counter = new RecyclingBinCounter(); ExecutorService service = Executors.newFixedThreadPool(3); for (int i = 0; i < 3; i++) { service.submit(() -> { for (int j = 0; j < 1000; j++) { counter.incrementBins(); } }); } service.shutdown(); while(!service.isTerminated()) {} System.out.println("Total bins collected: " + counter.getBinCount()); } }

Quel est le problème principal de la structure de solution choisie? - Absence de gestion des exceptions spéciales lors du démarrage - La classe de configuration sans annotations @Configuration - Mauvaise configuration des dépendances DI - Mauvaise intégration des configurations personnalisées modifie l'ordre de chargement des propriétés - Absence de @Autowired pour la présence de dépendances

Utilisation inefficace d'un pool de threads fixe Problèmes d'interaction avec les ressources partagées Une inclusion incorrecte du verrou peut conduire à une situation de blocage. Niveau de synchronisation incorrect Pas de vérifications de tous les threads avant le résultat Pas de constructeur explicite

Quel est le problème principal de cette implémentation SELECT f.food_id FROM Foods f JOIN Expirations e ON f.id = e.food_id WHERE e.is_expired = 1; - `JOIN` au lieu de `WHERE EXISTS` pour vérifier la présence d'enregistrements. - Pas d'index sur le champ e.is_expired - Les clés JOIN ne sont pas indexées - La table des dates de péremption est redondante - La requête n'est pas protégée dans une transaction

Quelles sont les principales stratégies de verrouillage utilisées par les bases de données pour gérer l'accès concurrentiel?

Comment intégreriez-vous le cycle de vie du Kafka Listener : via KafkaListenerEndpointRegistry ou un polling explicite avec KafkaConsumer ?

Que renvoie Postgres après avoir traité l'information et compris que les données existent ? Retourne-t-elle directement les données sous forme de carte de lignes ou autre chose ?

Quel est le problème principal de la structure de solution choisie? La classe Property ne supporte pas le polymorphisme. Les champs de la classe peuvent ne pas être initialisés. La méthode de transfert du calcul du coût total dans la classe "Order". N'utilise pas de mécanismes de transaction. Il n'y a pas d'exceptions en cas de liste vide.

Expliquez le cycle de vie d'un bean dans Spring.

Par quels flux ? (question de clarification après avoir mentionné les flux d'entrée/sortie)

Que faire si nous voulons faire la même chose avec DataSource?

Pourquoi avez-vous choisi wait/notify plutôt que ReentrantLock?

Parlez brièvement de l'architecture du service.

Quel effet secondaire se produit lors de l'exécution du code BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED; START TRANSACTION; SELECT progress INTO @current_progress FROM courses WHERE course_id = 101; SET @current_progress = @current_progress + 60; UPDATE courses SET progress = @current_progress WHERE course_id = 101; COMMIT; END; BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED; START TRANSACTION; SELECT progress INTO @current_progress FROM courses WHERE course_id = 101; SET @current_progress = @current_progress + 40; UPDATE courses SET progress = @current_progress WHERE course_id = 101; COMMIT; END;

Quel est le problème principal de cette implémentation du type composite dans la base de données? TIMESTAMP sans fuseau horaire Erreur de syntaxe! NULL dans le code Absence de CTE, lisibilité Problèmes de portabilité dus à SERIAL «TICKET_TYPE» n'a pas été déclaré dans la base de données Ce n'est pas la dernière valeur au niveau de INTEGER

Quels sont les problèmes de Spring Kafka avec les threads virtuels ? Ou il n'y en a pas du tout ?