在參考資料中，對斐波納契數列(Fibonacci)進行求解來展示RecursiveTask的用法，很好。
另外，在JSR166y演進的過程中，其算法經過調整，導致原示范代碼中存在一些問題，需要進行些許調整。歷史遺留代碼，如下：
Fibonacci f1 = new Fibonacci(n - 1);
f1.fork();
Fibonacci f2 = new Fibonacci(n - 2);
f2.fork();
return f2.join() + f1.join();
但現在已不建議使用。真要如此執行，會一直阻塞等待（至少我本機是如此）。查看RecursiveTask的源代碼，也發現示范doc中，兩個RecursiveTask類型結果相互匯聚，推薦示范為：
Fibonacci f1 = new Fibonacci(n - 1);
f1.fork();
Fibonacci f2 = new Fibonacci(n - 2);
return f2.compute() + f1.join();
嗯，這里同時提供一個單線程版本的參考實現，與之作為對比：
在測試時，發現速度太慢，于是萌生了改進了其算法的想法，于是一個非遞歸、單線程版本實現出現了：
使用JUNIT 4進行測試類：
該貼的代碼，都貼完了，可以預測一下哪一個算法的速度排名嗎 ？嗯，貼出運行JUNIT測試輸出結果吧：
Fork/Join 算法 ...
1836311903
用時 : 2203
單線程遞歸算法 ...
1836311903
用時 : 1016
單線程改進遞增算法 ...
1836311903
用時 : 0
在測試類中，把MAX設置為55或更大的數字，以上兩個算法就可能等待過長的時間（實在沒有耐心等待那么長時間），而算法三，即使設置再大，也是瞬時完成。
上面的測試類中，把results數組以static修飾，公共共享方式，存放在常量區，在速度上會比原始測試代碼讀取方面更為迅速，快了不少。
本機的CPU雙核的效果沒有體現出來。權威一些的解析：
在Java 7 生命周期內，大的（32+）多核系統將大量出現，有了這個框架可以讓人們對計算密集型任務獲得相對簡單的增速方法。目前，forkjoin在如Sun Niagaras和Azuls這樣的機器上工作得最好，它們只是即將普及的并行處理器。Forkjoin在標準SMP上工作的也不錯。總體來講，少于4處理器的話你不并能獲得太多增速效果——其主要目標是針對成打到成百處理器范圍。
另一方面，也是任務劃分過于細小，優勢體現不出來。當然，不是所有的任務都適合Fork/Join模式，以及適合多線程，就看具體任務具體分析了。