2011-01-06 12 views
6

Se si definisce il servizio in ambito Singleton nella configurazione di primavera, cosa accadrebbe se più di un utente tenta di accedervi (cioè come dipendenza iniettata nel controller) allo stesso tempo ? Dovrebbe causare qualche conflitto? O il contenitore IoC manterrà la chiamata successiva fino al completamento della prima? In tal caso dovrebbe rallentare le prestazioni in applicazioni di grandi dimensioni, il che non mi sembra giusto. Qualcuno potrebbe darmi una risposta corretta?Quando si accede a più istanze Spring Singleton contemporaneamente

BTW, come posso ricordare, se non è un singolo, il contenitore IoC raggrupperà poche istanze in base al numero di richieste. Qualcuno potrebbe confermarlo?

risposta

12

cosa accadrebbe se più di un utente tenta di accedervi (vale a dire come dipendenza iniettata nel controller) allo stesso tempo?

A un bean singleton è possibile accedere più volte contemporaneamente. Ecco perché deve sempre essere thread-safe

In caso di conflitto?

Solo se si riesce a fare è thread-safe

O il contenitore CIO si terrà la chiamata in seguito fino a quando il primo traguardo?

No, che sarebbe terribile


BTW, che posso ricordare, se non è un singleton uno, contenitore CIO si depositerà pochi casi in base al numero di richieste. Qualcuno potrebbe confermarlo?

Spring ha i seguenti scopi (see Bean Scopes reference):

  • singleton (solo un'istanza è gestita per applicazione)
  • prototype (una nuova istanza per ogni iniezione)
  • session (un'istanza per sessione HTTP, solo in Spring MVC)
  • request (un'istanza per richiesta HTTP, solo in Spring MVC)
  • global session (una sola istanza per ogni sessione HTTP globale, solo nel portlet basati su Spring MVC)

anche:

partire dalla primavera 3.0, un ambito di discussione è disponibile, ma non è stato registrato da predefinito.Per ulteriori informazioni, consultare la documentazione per SimpleThreadScope.

Quello che descrivi è un pool di oggetti. In primavera sarebbe implementato come Prototipo con ambito FactoryBean. E internamente userebbe una libreria come Apache Commons/Pool.

+0

Grazie per la risposta. Quale sarebbe la migliore pratica per rendere sicuro il thread della classe Singleton? Non credo che utilizzare il blocco di sincronizzazione sarebbe una buona idea, in quanto è troppo costoso per le prestazioni. – Brolinuk

+0

@Brolinuk A volte hai bisogno di blocchi sincronizzati, a volte no. Leggi [Concurrency in Practice] (http://www.javaconcurrencyinpractice.com/) per ulteriori riferimenti. Fondamentalmente: se non si dispone di uno stato mutabile, si è generalmente sicuri del thread. Se lo fai, avrai bisogno di un modo per sincronizzare l'accesso allo stato mutabile. C'è anche una [domanda SO pertinente] (http://stackoverflow.com/questions/1237980/java-5-concurrency-book-recommendations) –

4

I singleton sono proprio questo - singleton. Un'istanza è gestita dal contesto Spring e tutte le richieste passano contemporaneamente a quell'istanza. Spetta a te rendere sicuro quel thread.

Se il bean non è sicuro per i thread, prendere in considerazione l'utilizzo di bean con ambito non singleton. Spring ti consente di utilizzare ambiti di richiesta, sessione e prototipo.

+1

+1 se avessi punti per "fino a te per rendere quella thread-safe" – Kurru

Problemi correlati