我什么时候应该使用blockingGet？

我在工作中经常使用 RxJava，并且看到了一些调用返回 Observable 或 Single 的方法的示例，然后在其上调用blockingGet 以在不同的 .我认为这可能是对图书馆和概念的滥用，但我可能是错的。我举一个小例子：

   public Observable<String> getStrings(){
     // return sg
   }

   public Observable<String> getNames(){
     // return names
   }

   public Observable<String> filterNamesInStrings() {
     List<String> names = getNames().toList().blockingGet();

     return getStrings().filter(str -> /*is str in names list*/)
   }   

The filterNamesInStrings也可以通过以下方式解决：

   getNames()
    .toList()
    .flatMapObservable(names-> 
       getStrings().filter(str -> /*is str in names list*/)

我的直觉是第二个解决方案更好，但我唯一的原因是我觉得使用blockingGet我们打破了可观察量的链条，失去了懒惰（我不确定Rx有多懒）但我做到了找不到任何东西来证明我的观点，也没有什么可以进一步解释第二个更好。另外，如果我是对的，除了快速测试之外，我没有看到任何其他阻止 get 的用例，这是真的吗？

我的问题：

• 我的问题是否有效，或者实现之间的差异可以忽略不计？
• 是否有任何解决方案比其他解决方案更好/更符合库的要求，如果是的话，为什么以及是否有充分的理由使用blockingGet？
• （可选：你能给我推荐一本关于理解 ReactiveX 深度的好书吗？这样我就能得到对此类问题的解释，并且“良好实践”列表/书也会很方便）

我的问题是否有效，或者实现之间的差异可以忽略不计？

blockingGet阻止当前线程，因此您几乎肯定不想在测试之外调用它。第二个例子是正确的方法。

是否有任何解决方案比其他解决方案更好/更符合库的要求，如果是的话，为什么以及是否有充分的理由使用blockingGet？

主要是测试。或者很少，当使用完全同步的代码时，阻塞实际上从未发生。

理解ReactiveX的深度

没有一本书能达到如此深度。所有关于 RxJava 的书都很好读。