华为CodeCraft-2019复赛判题器Java实现 复赛判题器，和官方的一致，判题器和调度算法是合在一起使用的，将调度算法部分注释掉也能单独使用。因为是自己使用的，能够确保输出的答案的正确性，所以就没有将检查答案是否正确的那部分代码。 第一次参加这样大的比赛就写这么大的一个判题器，而却java也是干入门的，至于数据结构和算法就只能是边学边打比赛了，用了两天写代码，三天调bug才把判题器搞出来着实不容易啊，看到的兄弟给个星吧。
判题器思路： 基本上和官方给出的伪代码一致的，不同的地方可能是优先队列的计算了，官方应该是每次转弯完成后都计算有第一优先权的车，而我的判题器时在调度路上的车行驶后就一次性把一条路的车的优先队列算好，至于那些并不能转弯但由于前面的车是等待态的车而变为等待态加入到优先队列，在后面调度一条车道的算法中有单独处理。 死锁的判断也是十分简单的，在一次调度等待态的车时，没有车能够移动，就说明路上出现了死锁，再找到处于等待态的车，就可以找死锁的路口和路了。
调度算法思路： 初赛时凭借一个十分粗糙的控制车流量的动态规划算法成功进入复赛，之所以说粗糙是因为算法中计算车的位置的方法十分简单，忽略了很过东西，导致车的位置的就算不是很准，由于初赛时没有判题器，要准确计算车的位置也不可能，虽然说这样计算不准，但是通过这样计算出来的路径仍然比通过广度优先和迪杰斯特拉算法计算出来的路劲要好的多，但是不能避免死锁。 复赛时虽然有了判题器，本以为有了判题器就有了全世界，谁知道理想很美满，现实很骨感。通过判题器确实能够解开死锁，但是解开是说的效果却不好。我们解死锁的策略是利用判题器反馈回来的死锁车辆，死锁道路和死锁路口的数据优先为死锁车辆重新计算路径，如果找不到路径就延时或推前车的发车时间，这样做后确实能够解开死锁，放到官网上同样也不会死锁。但是一增大车流量，解开死锁的时间就会增加，这样做很容易就会达到瓶颈。由于我们判题器出来的晚，判题器是在比赛前2天才出来的，还没来得及研究怎样利用判题器比赛就开始了，真是拿着核武器不知道怎么用的感觉。 比赛结束后和大佬们交流才知道自己的调度算法的不足和没有好好利用判题器。我们复赛还是采用和初赛一样的粗略跟踪车的动态规划算法，有了判题器就应该要准确跟踪车的位置进行动态规划了，因为判题器能够准确提供每个时刻的车的位置的数据，在快要或者已经出现死锁时就可以用状态回退，回到之前的状态来重新规划车的路线。只可惜直到复赛开始我们还没有想到这样的方法。只能来年再战了。
不管比赛结果怎么样，在这次比赛过程中我都收获了很多，由java刚入门到比较熟练掌握java，由一点不了解数据结构和算法到开始了解数据结构和算法等等。不得不说参加比赛是一种很好的学习方式。