讲一下自己探索知识的心路历程

1. 知识为什么能探索的越来越深，是因为有需求。

就像如果我就是平常买买菜，那几何，高数，跟我有什么关系，一样的道理。因为用到了，而且还不满足，还可以更高更快更强....

 

之前做文件分片上传，尝试着在后端自己手写一个分片上传的逻辑。因为当时的计划是 java端swt程序 和 javaweb通信，java - java

这种形式其实很少（说白了就是不好找参考，更不要说有没有现成的轮子了），

但是当时基本上自己把轮子都造完了（而且swt端程序甚至没用spring，而是自己写了一套双重校验锁的单例机制），就剩一些

（1）.在UI线程里实时显示进度的问题。

因为当时我觉得应该是每一块文件分块作为进度，比如说分100块，每块多大，计算进度。但是还要求计算速度，那肯定就不能给前端显示成 0.4块/s 这种，不合理。而且我当时的监听回调也是以每块完成触发的。

只能说当时要做的时候，需求并没有完全定下来，导致我的设计并没有完全符合后续的需求，导致那个方案搁置，然后直接转成现在比较常用的方案（前端分片vue-uploader，后端存储，后端BufferedRandimAccessFile合并分片）。

现在传40G甚至128G的文件也是没有问题（当时是边做边测的）

当然，错误归错误。

收获还是很多，知道了双重校验锁的单例的写法（因为多线程在用这个），知道了线程池（当时的是计划每一个分片用一个线程去传）

（2）BufferedRandimAccessFile感觉会有内存溢出的风险（如果读取128G的文件）

当时做文件合并的时候，合并大文件，每次在内存中存放byte[]，当分片数很多的时候，在jconsole里老年代里很多释放不掉的内存。应该是byte[]使用方法错了，那就是一个闪存。

当时也研究了一下NIO，文件channel的方式感觉很特别。感觉像是一个队列， 所有人都可以从中取。

（3）如果没有事先制定计划，或者需求并没有稳定下来，可能会做很多无用功。

当时也做了注册表的调研，因为当时要从网页上点击一个按钮，然后弹出上传的客户端（类似于百度网盘或者迅雷，直接从页面可以调起），实际上他们是把自己信息注册到注册表里了，而且可以带参触发exe。

当时就感觉好神奇， 也清晰了一些操作到底是怎么实现的。

而且自己写了一个线程池来管理，多线程分片传输，可以说是把线程池那边都看了一遍，自带的那种拒绝策略和等待队列还有日常存活线程的方案，总感觉不是很能匹配现在的需求，于是自己定义了一个，但是后来整个swt方案暂时搁置了。

 

总之，比较凌乱没有主题的对于之前那个swt文件上传器的总结，从中获得了很多宝贵的经验和思路，应该算是一个开端吧。