题目与参赛代码：https://github.com/AllenDuke/kcodegit
这应该是我第一次参加计算机类比赛，除开学校举办的程序设计赛的话。我能感受到本身的水平提高了不少，学到了解决问题可从多个角度入手，尝试，用多个指标来衡量，而后挑出最优角度，最后从这个角度再出发，不断优化。github
通常个人思路以下：算法
先用单线程读取与处理，若是能够先作流式计算，不过最后仍是要和一次性读入进行比较。数组
再考虑更换好的数据结构和算法，接着更换为多线程并行计算。数据结构
利用特征，减小没必要要运算，如不判断是否为空，特别是要注意重写equal和hashCode方法，优化必要运算，如利用位运算，或者在某些特定场景下用加法代替乘法。多线程
重用对象，减小对象的产生，减轻gc，为此我本身设计了一个可重用的SDS来代替字符串拼接和StringBuilder，但彷佛拼接的量少时，如3个，拼接的速度更快。数据结构和算法
在内存足够时，增长冗余来减小链接，增长索引来减小无效遍历。函数
应该是止步复赛了，但我既不服气又服气。复赛线上用的应该是机械硬盘，多线程处理没有帮助，反而会加剧IO负担，那么你们都只能单线程处理了（但我认为本身在多线程上有优点的），估计一阶段你们都应该是差很少的，那么都在拼二阶段了。在优化二阶段的过程当中，我想到了在一阶段中提早查询来预热数据，那么二阶段就能够直接获取了，接着优化，我还想到了在(StringA,StringB)->StringC时，转换为Long->StringC，Long的高32位保存StringA的hashCode，低32位保存StringB的hashCode，减小String.hashCode运算，固然这是有hash冲突的风险的。最后我还想到了定制一个IntHashMap和LongHashMap用于肯定key位int为long的状况，以减小Integer和Long的产生，减小equal的无用判断。至此我认为本身已经优化到极限了，然而仍是比不上大佬们。学习
我不服气的是，我自认为的极限却仍是看不到大佬们的身影，我不服气的是大佬们轻易想到用数组（我用的是Map，尚未测试速度差了多少）和神奇的hash函数（我有尝试过更换好的hash函数，但总会冲突），我不服气的是，最后竟要输在纳秒级别的差别上。测试
我服气的是，大佬之因此是大佬，是由于大佬在什么时间，什么地点都是大佬。
不过我仍是挺满意的，由于在我本身看来，我有了很大的突破，而这种突破不会中止。在大佬们的讨论和开源的代码中，我学习到了不少，除了上述所说的神奇的hash函数外，还有JNI和各类优化手段，是很感激的！
不以物喜，不以己悲，继续学习。