In che modo il singleton Bean soddisfa la richiesta simultanea?

Question

Ho una domanda su come i bean singleton servono in dettaglio le richieste concorrenti.

Ho cercato su StackOverflow per quanto riguarda questa domanda. Questo è un campione link from stackoverflow, ma ho trovato solo dettagli di alto livello. Voglio i dettagli completi su come un bean singleton serve richieste concorrenti e su come il processore di sistema vedrà quelle richieste.

Ho studiato la gestione simultanea delle richieste nel processore di sistema online. Hanno detto che il processore stesso ha uno scheduler e che lo schedulatore deciderà quale richiesta verrà elaborata.

Ok bene. Se supponiamo di avere più di un core processor, in che modo lo scheduler gestisce le richieste concorrenti?

Qualcuno può spiegarmi la procedura dettagliata su come un bean singleton servirà richieste simultanee nella JVM e nel sistema?

Lasciatemi spiegare con un esempio concreto. Ho una classe come Sports:.

class Sports { 
    public void playFootball() { 
    } 

    public void playVolleyBall() { 
    } 
} 

due richieste sono disponibili in La prima richiesta è in esecuzione il metodo playFootball nell'istanza Singleton creato di classe Sports. Allo stesso tempo, un'altra richiesta sta eseguendo il metodo playVolleyBall sulla stessa istanza singleton creata della classe Sports.

Come è possibile con un'istanza singleton?

Answer 1

Singleton è un ambito per i bean. Devi gestire questo come servire per l'accesso a più thread. È possibile utilizzare la sincronizzazione o i pacchetti simultanei. Rif: Are Spring singleton beans thread-safe?

Per la richiesta concomitante, il bean singolo servirà per richieste multiple una per una.

Answer 2

Per conoscere in dettaglio Come il bean singleton serve la richiesta simultanea? dovete sapere le seguenti cose su Fagioli primavera

• Bean Scopes

  Primavera ha ambiti diversi di fagioli (ad esempio Prototype, Singleton, ecc), ma tutti questi ambiti di far rispettare è quando il fagiolo è creato. Ad esempio un bean con scope "prototipo" verrà creato ogni volta che questo bean viene "iniettato". mentre un bean con scope "Singleton" verrà creato una volta e condiviso all'interno del contesto dell'applicazione.
  "singleton" ambito è l'ambito predefinito di Spring Bean.

• Creazione di Bean

  L'intero ciclo di vita di Spring Bean è gestito dalla molla Container (cioè ApplicationContext/BeanFacotry) Spring Contenitore riferisce internamente la definizione bean (ieXML di base nota ot base) per creando istanze reali della classe definita dalla definizione di quel bean. ora quando il contenitore Spring viene avviato fa riferimento alla definizione del bean e instaza tutti i bean definiti.

• Richiedi il fagiolo.

  Ora quando l'oggetto effettua una richiesta al bean, Spring Container passerà il bean che è già inizializzato.

• Spring Bean Scope

• Are Spring objects thread safe?

• Spring Tutorial 11 - Understanding Bean Scopes

spero che questo ti possa aiutare ...

Answer 3

Un fagiolo singleton ideale non dovrebbe mantenere alcun stato. Ciò significa che non avrà alcuna variabile che memorizzi qualcosa di specifico per la richiesta che sta scontando.

Quindi, un bean singleton avrà semplicemente un codice stateless (ad esempio metodi controller) che può essere eseguito contemporaneamente per più richieste senza problemi di concorrenza.

Per esempio, se in seguito è stato il tuo fagioli Singleton:

@Service 
public class Calculator { 

    public int sum(int a, int b) { 
     return a + b; 
    } 

} 

In termini semplici, quando due "richieste" invocano sum metodo del fagiolo, allo stesso tempo, ciò significherebbe il metodo sum sarebbe eseguita contemporaneamente in due diversi thread. Quindi avranno il loro contesto di esecuzione che non si sovrapporrà l'un l'altro. Ciò consentirebbe tranquillamente loro di funzionare contemporaneamente.

Se lo stesso bean doveva avere indicano quanto segue:

@Service 
public class Calculator { 

    int incrementalMultiplier = 0; 

    public int mulitply(int a, int b) { 
     incrementalMultiplier++; 
     return a * b * incrementalMultiplier; 
    } 

} 

Ciò può causare problemi quando serve due richieste contemporaneamente perché l'incrementalMultiplier è stato livello oggetto che verrà condiviso dalle due richieste (fili) e quindi potrebbe produrre risultati inaspettati.

In breve un singleton stateless sarà in grado di servire due richieste contemporaneamente perché saranno in thread diversi.

Answer 4

Saravan Kumar,

Capisco la motivazione dietro alla tua domanda. Prima di iniziare a lavorare sui compilatori, avevo anche un simile desiderio di conoscere gli interni della Java Virtual Machine.

Prima di tutto, sono impressionato dalla tua domanda. Ci devono essere un paio di punti di distinzione e comprensione per risolvere la tua domanda. Primo: un pattern Singleton, o talvolta anche un anti-pattern, assicura che ci sia solo una istanza di questa classe disponibile per JVM. Ciò significa che stiamo essenzialmente introducendo uno stato globale in un'applicazione. So che lo capisci, ma è solo un punto di chiarimento.

Ora gli interni.

Quando creiamo un'istanza di una classe, stiamo creando un oggetto che risiede nella memoria condivisa di JVM. Ora questi thread eseguono indipendentemente il codice che opera su queste istanze. Ogni thread ha una memoria di lavoro, in cui conserva i dati dalla memoria principale condivisa tra tutti i thread. Qui è dove risiede il riferimento all'oggetto Singleton che hai creato. In sostanza, ciò che sta accadendo è che il codice byte che è stato generato ed è rappresentativo dell'oggetto singleton che hai creato viene eseguito su ognuno di questi thread.

Ora la struttura interna di come questo accade è la seguente:

Ogni thread macchina virtuale Java ha una macchina virtuale Java stack di privato, creato allo stesso tempo come filo. Ora, la macchina virtuale Java ha un heap condiviso tra tutti i thread della macchina virtuale Java. L'heap è l'area dati di runtime da cui viene allocata la memoria per tutte le istanze e gli array di classe. L'heap viene creato all'avvio della macchina virtuale. Quando il thread richiede l'istanza singleton, punta a un riferimento nell'heap in cui risiede il codice byte per questo Singleton. Sta per eseguire il codice appropriato, nel tuo caso sta per eseguire il primo metodo per la prima richiesta e il secondo metodo per la seconda richiesta. È in grado di farlo perché non ci sono blocchi o restrizioni che impediscono al compilatore di puntare il contatore del programma sull'area dell'heap su cui è allocata questa istanza. L'unica restrizione che la classe Singleton mette sulla Java Virtual Machine è che può avere solo un'istanza nell'heap di questa classe. Questo è semplicemente. Oltre a questo, puoi farvi riferimento 100 volte dal tuo metodo, il compilatore punta allo stesso codice byte e semplicemente lo esegue. Questo è il motivo per cui in genere si desidera che la classe Singleton sia stateless, perché se si accede a qualsiasi thread, non vogliamo che le variabili interne vengano mutate a causa della mancanza di controllo della concorrenza.

Per favore fatemi sapere se avete domande!

Answer 5

Ho visto molte ammonizioni per mantenere i bean singleton condivisi privi di stato e volevo presentare un caso d'uso in cui un singleton stateful in un bean di supporto di un'app Web ha senso.

Ho un'app Web amministrativa che, su richiesta, richiede due sistemi separati (un CRM e un Digital Assets Manager - DAM) per i dati utente, confronta i record e aggiorna il DAM di conseguenza utilizzando la sua API. Questo a volte richiede molto tempo se ci sono molti aggiornamenti. L'interfaccia utente Web mostra lo stato degli aggiornamenti in tempo reale, poiché il browser esegue il polling del bean di supporto utilizzando ajax ogni secondo per visualizzare una barra di avanzamento e quanti account utente è stato elaborato. L'interfaccia utente fornisce anche un pulsante per avviare il processo di sincronizzazione e un pulsante per interromperlo. Il pulsante di sincronizzazione è inizialmente abilitato e il pulsante stop non viene visualizzato. Dopo che l'utente fa clic sul pulsante di avvio, il pulsante di avvio è disabilitato e il pulsante di arresto è abilitato.

Mentre la sincronizzazione è attiva, voglio diversi client (diversi utenti alla tastiera che usano l'app Web nei loro browser separati) per vedere lo stesso stato, cioè la barra di avanzamento e il numero di account utente elaborati e gli stati del pulsante. Questo è importante perché non ha senso avviare un secondo processo di sincronizzazione mentre uno è già in corso.