YouTube Videos

A Simple Neural Network
KotlinConf 2018 - Mathematical Modeling
Creating a Sudoku Solver from Scratch
Traveling Salesman Problem
Text Categorization w/ Naive Bayes
Monty Hall Problem
Solving World's Hardest Sudoku

Sunday, March 20, 2016

RxJava - The Problem with Subjects

Subjects are both an Observable and an Observer. Because it is an Observer, anything at any time can call its onNext() method and push items up to its Subscribers. You can also take one or more existing Observables and have a Subject subscribe to them, and in turn pass their emissions up to the Subject's Subscribers. These features may seem convenient but can quickly encourage anti-patterns.

When I first started learning reactive programming, I was quickly introduced to the Subject and its various flavors like BehaviorSubject, ReplaySubject, and PublishSubject. To a newbie with an imperative programming background, these seemed like magical devices that bridged imperative and reactive operations together. I began to think subjects were a practical way to create source Observables, and I could push items from any source at any time through a chain of reactive operations. Makes sense right? Even some reactive tutorials encourage newbies to play with Subjects to get a feel for reactive programming, but I think this is wrong and creates a setback in a newbie's learning curve.

If you find yourself using Subjects quite often, you might want to reflect on what you think a source Observable does. On a philosophical level, reactive programming is about defining behaviors from a well-defined source all the way to the Subscriber. It is important to think about how emissions should originate and take form.

But first let's discuss ideally how a reactive chain of Observables should work, and then later it will make sense why Subjects can undermine the integrity of a reactive application.

A Typical Observable Setup

From a practical standpoint, an Observable chain of operations is broken into three parts:

1) The Source Observable where emissions originate
2) Operators to transform the emissions
3) A Subscriber to consume the emissions

Of course, we can make #2 more complicated by using operators that work with other Observables, like merge() and flatMap(). But every Observable by itself should follow this structure. The simplest example would be emitting a fixed set of String values, mapping their lengths, and then printing them.

Observable<String> values = Observable.just("Alpha", "Beta", "Gamma");

Observable<Integer> lengths =;

Subscription printSubscription = lengths.subscribe(System.out::println);

The three components, the source, the operators, and subscriber are very distinctly identified above. We can alternatively express this in one statement without intermediary variables.

//Source, Operators, Subscriber
Observable.just("Alpha", "Beta", "Gamma")

This entire Observable operation is also agnostic to which thread it is scheduled on, which is good for flexible concurrency and works easily with observeOn() and subscribeOn() as we will read about in Reason 3. But first let's just look at source Observables themselves and analyze their nature.

Reason 1: Keep Source Observables Predictable

What needs to be highlighted with the example above is the source emitting "Alpha", "Beta", and "Gamma". The Observable.just() factory created a source Observable emitting these three Strings. The benefit is the source is tightly controlled and predictable, and we know it will only emit those three Strings. We can trust nothing alien is ever going to enter that source and and be emitted up the chain.

For instance, we should never expect the word "Puppy" to be emitted by the source. We only expect "Alpha", "Beta", and "Gamma".

Observable.just("Alpha", "Beta", "Gamma")

However if we use a Subject, this is not guaranteed, especially if it is exposed publicly and anything can call its onNext() method. (Not to mention, this is just downright messy compared to the code above).

PublishSubject<String> subject = PublishSubject.create();


//something accidentally pushes "Puppy" as an emission


The Subject undermines having a well-thought, strictly-defined source Observable where the emissions come from a predictable source. You also lose some flexibility as the Subject is hot, and you can no longer create a cold Observable as we will read in #2.

This is a simplistic example of course, and more complex applications are not going to emit three emissions like "Alpha", "Beta", and "Gamma". Realistically, you might use RxJava-JDBC to create a source Observable which emits items from a database query.

Database db = ...

Observable<String> values = db
        .select("SELECT MY_FIELD FROM MY_TABLE")


While the results of the query can change each time it is subscribed to (because the table can be updated), we have strictly defined the source Observable and where its emissions come from. It will only emit items from this query and nowhere else.

You can even avoid Subjects for hot sources too. A JavaFX Button being pressed, for example, can emit those action events in a hot Observable. We can use Observable.create() instead of a Subject to turn those events into an Observable.

Button button = new Button("Press Me");

Observable<ActionEvent> actionEvents =  Observable.create(new Observable.OnSubscribe<ActionEvent>() {
    public void call(final Subscriber<? super ActionEvent> subscriber) {
        final EventHandler<ActionEvent> handler = subscriber::onNext;

        button.addEventHandler(ActionEvent.ACTION, handler);

        subscriber.add(JavaFxSubscriptions.unsubscribeInEventDispatchThread(() -> 
            button.removeEventHandler(ActionEvent.ACTION, handler)));

actionEvents.subscribe(ae -> System.out.println("Pressed!"));

Even better, we can use RxJavaFX and call a factory that does this for us.

Button button = new Button("Press Me");

Observable<ActionEvent> actionEvents = JavaFxObservable.fromActionEvents(button);

actionEvents.subscribe(ae -> System.out.println("Pressed!"));

This way we can be sure that emissions for this source Observable will only come from this Button being pressed.

To summarize all the examples above, we should tightly control how a source Observable works and strictly define where its emissions come from. Having a Subject haphazardly allow emissions to come from any source can create a chaotic, unmaintainable application.

Reason 2: Mind Your Hots and Colds

The best definition I have heard of a Cold Observable versus a Hot Observable is by Nickolay Tsvetinov, author of Learning Reactive Programming with Java 8:
We can say that cold Observables generate notifications for each subscriber and hot
Observables are always running, broadcasting notifications to all of their subscribers.
Think of a hot Observable as a radio station. All of the listeners that are listening to
it at this moment listen to the same song. A cold Observable is a music CD. Many
people can buy it and listen to it independently.
A cold Observable is "replayable", meaning it will "replay" its emissions to each Subscriber independently. A hot Observable will emit the same item at a given time to all its Subscribers, and it may not even care if any Subscribers are present.

Some things are more appropriately represented as a hot Observable, such as UI input events like a Button getting pressed. Data-driven Observables, such as the earlier example emitting "Alpha", "Beta", and "Gamma" or the database query, are often better represented as a cold Observable. That data is replayed to each Subscriber that needs it, and being cold guarantees no data was missed previously. Sometimes, it is more efficient to carefully play expensive emissions at the same time to all Subscribers, and this is where a ConnectableObervable can come in handy to turn a cold Observable into a hot one.

But you need to be careful! Hot Observables are a timing-sensitive animal. This is why it is very important to prefer cold Observables by default. Many operators like flatMap() are in fact a Subscriber to another Observable. When used with hot Observables, this can lead to complicated, confusing cases where the data is being emitted in live time and not every Subscriber is able to capture all the data if they subscribed too late.

For example, lets say we have three Strings being emitted from a source Observable. We want to subtract their lengths from the min length of the three Strings. We can wrongly use a PublishSubject to hotly emit the Strings to a minLength Observable and a Subscriber that flatMaps against this minLength.

PublishSubject<String> source = PublishSubject.create();

Observable<Integer> minLength = source
        .reduce((x,y) -> x < y ? x : y);
        .flatMap(len -> -> len - min))



But if you run this you may get an error or no console output at all. Why? The three values are being emitted hotly and the minLength can miss the emissions in the flatMap(). This would happen not just with a Subject but any hot Observable, including a ConnectableObservable.

But if you use the Observable.just() factory, it will coldly replay the values each time it is subscribed to. The flatMap() will subscribe to the minLength, which will subscribe to the source and replay the data each time. This way every part of the Observable chain is given ALL the data. Each piece can replay the CD rather than worrying it missed the radio program.

Observable<String> source = Observable.just("Alpha","Beta","Gamma");

Observable<Integer> minLength = source
        .reduce((x,y) -> x < y ? x : y);
        .flatMap(len -> -> len - min))

Also, is the code just not simpler? Cold Observables tend to make programs simpler and more reliable, and they should be preferred when possible. Yes, you could use caching of some form but this is often not good for performance. It is better for the cold source Observable to define how data is provided.

By the way, also be very mindful of infinite Observables and only use them when your source is truly infinite (like UI input events). Overusing infinite hot Observable can clash with operators that expect a finite set of emissions, and this hardly works well with complex reactive applications.

Reason 3: Thread Safety and Concurrency

Last but definitely not least, SUBJECTS BY DEFAULT ARE NOT THREADSAFE. This is a big reason to avoid them because reactive programming is all about making Observables safely agnostic to which threads they operate on. But if multiple concurrent calls to onNext() are occurring on different threads, it will break the Observable Contract and risk creating race conditions with the operators. Only one thread can be passing through a given operator at a time. But if the source Observable is making several simultaneous onNext() calls, it could have catastrophic behaviors.

If you use the existing Observable factories and operators with RxJava, you can be safely sure that you will not have this issue. Subjects, incorrectly-built custom Transformers, and bad sources with concurrent calls to onNext() can all wreak havoc.

If you do have to use Subjects for those corner cases, it is always a good idea to turn your Subject into a SerializedSubject. That way if multiple threads do happen to call the onNext() concurrently, it will serialize the emissions safely so it does not break any Observables and Subscribers dependent on it.

SerializedSubject<Integer,Integer> subject =

To learn more about concurrency with RxJava, read my article on observeOn() and subscribeOn().


Subjects are abused a lot and can undermine the benefits of reactive programming. Erik Meijer called them the "mutable variables" of reactive programming for good reason. Actually, the problems of mutable variables are almost identical to that of subjects: thread safety, bugs, not being sure where a value change came from, etc. An Observable is an immutable chain of operations from the source to the Subscriber, and the emissions are pushed in a predictable, contained manner. A Subject introduces mutability to that chain and can break it with unpredictable emission sources, lost data, and unwanted thread safety behaviors.

Of course there are some uses for Subjects and they can come in handy, but I avoid subjects 99.9% of the time and am better off because of it. I am sure there are other technical reasons to avoid Subjects, and these are just my observations and experiences. Let me know if you have other reasons they should be avoided, or corner cases when they should be used.


  1. Hi Thomas,

    thank you for this interesting article and +1 for the Tsvetinov's book citation (maybe the best until now IMHO).
    I just starting using RxJava and one thing that continues to confuse me is the usage of cold observables for UI events. I think that it is more "natural" to use a Subject (exposed as an Observable to clients if necessary) given that (think about the click listener of the example) it will pass the emissions the UI generates when subsribers are subscribed. The javadoc for the create() method of the Observable class states "Returns an Observable that will execute the specified function when a Subscriber subscribes to it.". Thinking about it when the source are click events for example still confuses me.
    Anyway, I see other similar implementations to the one provided above (on RxBindings for Android for example) but it still does not convince me.
    A further explanation would be much appreciated :)



    1. Thanks Paolo, I'm glad you found it helpful :)

      Regarding UI events, yes it may feel more natural to use Subjects and perhaps it is *more* appropriate than other cases. But there still is a better way. The Observable.create() can be used to create hot Observables and not just cold ones.

      For instance, consider the Button example I showed earlier. Anything that follows a Listener convention can likely be turned into a hot Observable in this manner. If you study it long enough, you will see it is not as complex as it looks. On Subscription, a Listener is created that will call onNext() each time it is fired. The unsubscription is also handled by removing the Listener when it is done. This critical unsubscription behavior is a bit less straightforward to do with Subjects.

      Of course, it is a bit verbose and this is why it is a good idea to use RxBindings, RxJavaFX, or other libraries that provide source Observable factories for you.

    2. Great article. I already read other people writing about PublishSubjects being somehow wrong, but none of them explained exactly why, but you just did. Thanks for this

    3. Exactly why I wrote this. Glad you found it helpful!

  2. Thanks Thomas, now I got it.

  3. Subjects are often FAR better then calling Observable.create().

    The reason is that creating an observable is MUCH harder then one could think and you need to know the internals of RxJava to build one that take into account everything an Observable should.

    Subjects on the other way do all that correctly out of the box.
    Sure, you need to be careful calling onNext on the right thread but you can assure that easily enough and I think it's the only real gotcha with using Subjects (or Relay).

    Just wrap subject in a class, and DO NOT expose them, return them with subject.asObservable() and provide methods (if needed) to push stuff into it that make sure they use the right thread.


    1. There are many implications in using Subjects that make them less of a candidate than Observable.create(), like backpressure and concurrency issues. Observable.create() should be avoided as much as possible too, but there are fare more gotchas with subjects.

    2. backpressure and concurrency issues can both be handled and sometimes easier in Subjects. There is nothings bad or wrong about Subjects and they are super useful to decouple modules while keep decouple cross functional messaging clear. Saying do not use Subjects 99.99% to newbies can led to them reinvent stuff and mess it up. In case of fully Rx components available you may end up using 99.99% only Subjects to wire things up, and there is nothing wrong about it.

    3. Funny you say that. I don't know if I agree completely with all your sentiments, but I do agree with your thoughts on decoupling modules. I have relaxed my views on Subjects slightly in the past month or two as I have ran into this problem. Situations where you need an "event bus" in some form, or an "event model", I can see those as valid use cases for Subjects. I've even created a CompositeObservable type in the RxJavaFX library to fulfill this need. If I didn't have that and some utilities JavaFX provided, I probably would have to use Subjects.

      Regardless, I think Subjects are one of those things that should be learned out of need rather than be introduced upfront. For newbies, they attract anti-patterns and should be used as a last resort, or decoupling modue

  4. While working with Couchbase client and Spring Cloud Sleuth, I found an issue with how Couchbase uses Subject. Sleuth relies on the RxJava Scheduler hooks to continue the trace and span id; the code is in SleuthRxJavaSchedulersHook of spring-cloud-sleuth project. AbstractCouchbaseRequest of couchbase-jvm-core project creates a subject AsyncSubject.create() that bypasses the RxJava hooks. Hence, Sleuth can't trace the Couchbase queries made.

    This is a simplistic but correct view of the problem, and since Markdown is not supported, I didn't provide direct links to the classes I referred to (but you can find them easily using the keywords I used). Do you've any suggestions on how to fix this?

  5. this is really a serious issue which need to be considered.

  6. I found this is an informative blog and also very useful and knowledgeable. I would like to thank you for the efforts you have made in writing this blog

  7. Thank you so much for this Post and all the best for your future. You are really a talented person I have ever seen. I am satisfied with the arrangement of your post i think i must share here

  8. Thank you for sharing this article. It is an amazing post, I am really impressed by your post. It’s really useful

  9. Dear Admin, you have shared very informative information with us through your article. this information is very useful for me and you are doing amazing work keep it up. I want also to share something with you. Thank you so much for sharing this and I wish you all the best for the upcoming article., Norton product key

  10. Wow, What an incredible blog you have shared with us, The content quality and the way you have describe it is amazing all information is very useful for me. Thank you so much for such an amazing blog and wish you the best of luck for the next comment and I also want to share some useful links here., Office product key,

  11. I am sure this article has touched all the internet users, its really really nice piece of writing on building up new webpage.

  12. I am very happy to read your article whenever I read it I found something new and interested information in your blog. Thank you so much for share this informative information with us and all the best for the next comment.,, mcafee activation code,

  13. To summarize all the examples above, we should tightly control how a source Observable works and strictly define where its emissions come from. Having a Subject haphazardly allow emissions to come from any source can create a chaotic, unmaintainable application. crushed velvet sofa covers , velvet plush fitted bed sheet

  14. I savour, lead to I found exactly what I used to be having a look for. You’ve ended my four day long hunt! God Bless you man. Have a nice day. Bye 메이저사이트

  15. I used to be suggested this blog through my cousin. I’m no longer sure whether this submit is written through him as
    nobody else understand such detailed approximately my trouble.
    You’re wonderful! Thank you! 경마사이트

  16. I really enjoyed this blog post, thank you for sharing it. I’ll return for more. See you soon! 카지노사이트

  17. This paragraph will help the internet visitors for building up new web site or even a weblog from start to end. 토토

  18. Dynamic Health Care products offer Sea moss which are spiny sea vegetable that’s primarily harvested for use in health supplements and as a thickening ingredient in commercial foods.
    If you’ve heard about sea moss supplements, you may wonder how you could use them and whether there are other ways to consume sea moss. For more information on our products you can visit our website by clicking the link Dyanmic Health Care Products

    sea moss near me
    How to make sea moss gel
    How to use sea moss gel
    How long does sea moss gel last
    Purple sea moss
    sea moss and bladderwrack
    Where to buy sea moss
    Sea moss capsules
    Where to buy sea moss

  19. This comment has been removed by the author.

  20. Nice post, you give the clear idea of the topic and I subscribed your blog, I have some links to share here

    buy ativan 1mg

    order valium

    buy xanax 2mg

    Buy Clonazepam 2mg online

    buy ambien 10mg online


  22. Hello!,I love your writing very so much! percentage we be
    in contact more approximately..
    You can safely browse our links for more information about our services....

  23. Hi! This is my first comment here so I just wanted to give a quick shout out and say I genuinely enjoy reading your blog posts.

  24. Nice Post!!
    Please look here at Preparation of Sea Moss is very easy and hence can be added at any time according to your wishes and needs. Sea Moss Gel is usually made from raw dried Sea Moss.

  25. Such A NICE pOST
    It will be appreciated if you follow this link:
    best seo expert in bangladesh

  26. This is a great web site. Good sparkling user interface and very informative blogs. Thanks

  27. I finally found great post here. Thanks for the information. Please keep sharing more articles.

  28. Thank you for sharing this information. I read your blog and I can't stop my self to read your full blog. Again Thanks and Best of luck to your next Blog in future.

  29. Thank you for sharing this useful article. Keep it up! Regards!

  30. Excellent Blog! I would like to thank you for the efforts you have made in writing this post.

  31. This is the post I was looking for 메이저사이트 I am very happy to finally read about the Thank you very much. Your post was of great help to me. If you are interested in the column I wrote, please visit my site .

  32. Thank you so much for this interesting article. ! So helpful!
    iqos heets dubai

  33. Excellent goods from you, man. I have understand your stuff previous to and you are just extremely excellent. Feel free to visit my website; 안전놀이터

  34. Hey! This post could not be written any better! Reading this post reminds me of my previous room mate! He always kept talking about this. I will forward this article to him. Fairly certain he will have a good read. Thank you for sharing! Feel free to visit my website; 카지노

  35. Good day! This post could not be written any better! Reading this post reminds me of my previous room mate! He always kept chatting about this. I will forward this page to him. Pretty sure he will have a good read. Thanks for sharing. Feel free to visit my website; 토토

  36. Hi there, I simply hopped over in your website by way of StumbleUpon. Now not one thing I’d typically learn, but I favored your emotions none the less. Thank you for making something worth reading. 먹튀검증업체

  37. Howdy! Do you know if they make any plugins to assist with SEO? I’m trying to get my blog to rank for some targeted keywords but I’m not seeing very good results. If you know of any please share. Cheers! 안전토토사이트

  38. Hey, Your blog is very informative. It is nice to read such high-quality content. Attractive information on your blog, thank you for taking the time and share with us. Thanks

  39. With Down To Earth™, you can choose from a variety of unique products at different storage temperatures that meet your personal needs—whether it’s for anxiety, pain or inflammation. You can also customize your product with a variety of ratios and blends to meet your specific expectations. Hurry up and order CBD Oil Online

  40. What a post I've been looking for! I'm very happy to finally read this post. 토토사이트 Thank you very much. Can I refer to your post on my website? Your post touched me a lot and helped me a lot. If you have any questions, please visit my site and read what kind of posts I am posting. I am sure it will be interesting.

  41. Everything is very open with a precise explanation of the issues 카지노사이트

  42. It was really informative. Your website is useful. 카지노사이트

  43. If more people that write articles really concerned themselves with writing great content like you, more readers would be interested in their writings. 카지노사이트

  44. แนะนำ เกมสล็อต Mega Gameเว็บสล็อตออนไลน์ น้องใหม่ล่าสุด ที่รวบรวมเกมสล็อตออนไลน์จากค่ายเกมชั้นนำ รวบรวมไว้ที่นี่ที่เดียว ปลอดภัย ด้วยระบบฝากถอนออโต้ ทีมงานบรืการตลอด 24 ชั่วโมงpg slot

  45. That's a great article! The neatly organized content is good to see. Can I quote a blog and write it on my blog? My blog has a variety of communities including these articles. Would you like to visit me later? 메이저안전놀이터