真的有必要用rxjava吗？
1、Rxjava逻辑会比较清晰，蛋代码可读性比较差；用在后台的业务处理上，后台业务通常复杂，步骤多，这会让逻辑更清晰，但是前端基本上没有必要用，而且代码可读性比较差；
2、ReTrofit每次发起请求都会创建OkHttp，不会复用，导致单条数据的请求性能低了一倍以上；
3、Rxjava+ReTrofit组合起来运行的性能非常低，特别是并发的时候，性能更低，测试发现并发100条要1200ms，不使用的话并发130ms；
4、Rxjava+ReTrofit组合当需要读取本地缓存的时候，读缓存是通过URL作为KEY来读取，这样就需要写两遍的URL，一遍是框架用的，一遍是用于缓存的，使用起来更不方便；以上是本人使用过程中的经历，有没有高手解惑，目前决定放弃这套组合，自己实现一套
localcache是什么文件？
localcache是一个纯java的在进程中的缓存文件，它具有以下特性：快速，简单，为Hibernate2.1充当可插入的缓存，最小的依赖性，全面的文档和测试。
过期失效的缓存元素无法被GC掉，时间越长缓存越多，内存占用越大，导致内存泄漏的概率越大。
java文件保存与打开？
可以通过BufferedReader 流的形式进行流读取，之后通过readLine方法获取到每行的内容，之后通过OutputStreamWriter进行文件写入。 BufferedReader bre = null;OutputStreamWriter pw = null;//定义一个流try {String file = "D:/test/test.txt"
;bre = new BufferedReader(new FileReader(file))
;//此时获取到的bre就是整个文件的缓存流pw = new OutputStreamWriter(new FileOutputStream(“D:/test.txt”),"GBK")
;//确认流的输出文件和编码格式，此过程创建了“test.txt”实例while ((str = bre.readLine())!= null) // 判断最后一行不存在，为空结束循环{pw.write(str )
;//将要写入文件的内容，写入到新文件}；
pw.close()
;//关闭流bre .close()
;//关闭流备注：文件流用完之后必须及时通过close方法关闭，否则会一直处于打开状态，直至程序停止，增加系统负担。
Java服务，内存OOM问题如何快速定位？
要快速定位无非就三步：dump内存文件，内存分析工具生成内存泄露分析报告，根据报告到代码中分析相关代码；
1.dump内存文件
./jmap -dump:format=b,file=heap.hprof pid
2.内存分析
常用的内存分析工具如：MemoryAnalyzer，jprofiler；工具会帮助我们快速的生成一份内存泄露分析报告，大致如下所示：
可以根据上面的问题描述去相关代码中，然后进行代码分析；
3.代码分析
在代码分析之前，我们大概理一下都会有哪些情况出现OOM；大体上可以分为几类类情况：JVM本身分配的内存过小，分配的内存不小代码可优化，分配的内存不小存在内存泄漏；
1.JVM本身分配的内存过小
这种情况一般比较少见，一般配置内存至少1G内存以上；常见的比如查询数据库几十条，上百条数据内存就不够用了，加内存可以立马能解决问题的；
2.分配的内存不小代码可优化
这种问题就比较常见了，内存本身配置的并不小，但是出现OOM；
常见的比如以下查出几千上万条数据库记录，导致内存不够用，这种情况可以分批次查询；
本地缓存，但是没有提供清除策略，导致内存越来越大，这时候需要指定清除策略比如lru策略；
导入一个文件比如excel，一下全部加载到内存中，导致内存OOM，这时候可以换一种读取的方式，通过流读取方式；
3.分配的内存不小存在内存泄漏
这种问题就比较难发现了，开发者任务应该清除的内存并没有清除，一直存在内存中，导致数据越积越多，最终导致内存OOM；常见的比如hashset因为修改计算hash值的数据导致内存泄漏；
本人之前遇到过的内存溢出分析实战：
Poi读取Excel引发的内存溢出
某Java服务（假设PID=10765）出现了OOM，最常见的原因为：
- 有可能是内存分配确实过小，而正常业务使用了大量内存
- 某一个对象被频繁申请，却没有释放，内存不断泄漏，导致内存耗尽
- 某一个资源被频繁申请，系统资源耗尽，例如：不断创建线程，不断发起网络连接
- pstree
- netstat
- /proc/${PID}/fd
- /proc/${PID}/task