修改代码:
bt2_1.run(); 而非调用AppContext.getTaskManager().scheduleTask(bt2_1);
打印:
这样的结果很奇怪.
执行内部子任务开始
线程执行 : 2_1
--执行购买任务--
--当前玩家金钱为 : 9--
--购买后玩家金钱为 : 8--
线程结束 : 2_1
执行了 : 94 毫秒
执行内部子任务结束
该实例并非如实例一中,等待父类task完成后再执行,如同,多线程当中的,run()与start()一样.
值的提醒的是:
线程执行 : 1_1
--执行购买任务--
--当前玩家金钱为 : 10--
--购买后玩家金钱为 : 9--
执行内部子任务开始
线程执行 : 2_1
--执行购买任务--
--当前玩家金钱为 : 9--
--购买后玩家金钱为 : 8--
线程结束 : 2_1
执行了 : 94 毫秒
执行内部子任务结束
线程结束 : 1_1
执行了 : 94 毫秒
前后打印的都是94毫秒,这肯定是不正确的,因为任务2_1执行了94毫秒,1_1还需要执行至少90毫秒.1_1 应当是90+94.可打印却是94毫秒,根据我的分析,这肯定是task超时100ms导致的再执行.其后的
--当前玩家金钱为 : 10--
--购买后玩家金钱为 : 9--
--当前玩家金钱为 : 9--
--购买后玩家金钱为 : 8--
--当前玩家金钱为 : 10-- --当前玩家金钱为 : 9--
--购买后玩家金钱为 : 9--
--购买后玩家金钱为 : 8--
一直不改变印证了这一点,所以,这样形式的调用task是错误的.这只是将一个task当做一个函数在调用!
即便将task存放private ManagedReference<BuyTask2> subTaskRef.依旧同上...
--当前玩家金钱为 : 10-- --当前玩家金钱为 : 9--
--购买后玩家金钱为 : 9--
--购买后玩家金钱为 : 8--
本文通过一个具体的任务调度案例,深入分析了任务执行过程中存在的问题,特别是关于任务间的时间同步及资源状态更新的问题。揭示了直接调用任务run方法与通过任务管理器调度之间的区别。
493

被折叠的 条评论
为什么被折叠?



