bug修复源码

⑴ android 源码自带播放器专辑封面显示有问题,这个bug怎么解决

刷机，要不然就用第三方软件

⑵ hive join数据错误

我们生产使用的hive3.1.2版本，hadoop也是3版本，用户通过使用hive发现join数据错误。分析SQL发现，当3表(含3表)以上，hive join出来的数据是错误。后来我通过测试发现，不管是left join、inner join还是right join，数据都会出现错误，通过后来的其他测试发现，两个表使用in和exists作为条件查询，出来的数据也是错误的。这是hive3的一个重大bug，使用hive3的小心了。

这个bug纠缠了我好久，后来定位出来hive的bug，我们生产环境通过修改hive源码已经修复了该bug。分析发现hive从2.6.1版本就开始有这个bug

in 和exists案例sql:

⑶ 求大唐双龙传mud无明显bug的mudlib源代码

有偿的话可以帮你手动修复bug，并且把driver给你换成最新的fluffos

⑷ 我有一个android app 的apk安装到了手机上 但是现在出现bug ,没有源码请问如何调试bug ,求大神们指点哈！

1.给手机安装驱动(可以通过**助手，*夹安装)

2.网络搜索个adb工具包，
3.命令行里切换到工具包里面，运行
adb logcat
出现bug的时候会发现连续数行代exception的log就是出错原因

⑸ 关于数据恢复的C++程序源代码，50金请高手帮忙改掉两个bug改可以生成exe的cpp文件，跪谢！

呃。。。。

inttrue=1;

你的代码中1161的定义的变量true ，，它是c++关键字，不能做为变量标识符。

你把她们都改成 比如 itrue就好了，

intitrue=1;//下面使用到的地方也都改成itrue

⑹ [探讨]提高代码质量的方法有哪些

1. 代码风格和规范：

多看看网上的一些代码规范，仔细思考一下制定这些规范的出发点是什么。例如Oracle（前

SUN)公司的代码规范，Google的代码规范 。

2. 学习最佳实践

在编码中遇到的各种大大小小的问题，首先不是自己去“闭门造车”的冥思苦想，多用

Google，搜搜是否已经有现成的解决方案。

3. 阅读优秀的开源代码

网上有很多优秀的开源项目，针对你自己项目中遇到的问题，找找类似的开源项目，学习、

研究，最重要的是变成自己的东西。

4. 学好英语

英语是目前所有编程语言的基础。你的文件名、类名、方法名、变量名都是需要一个好的英

语基础才能够起得合适。任何的业务逻辑，都需要你使用以英语为基础的计算机语言表达出来。

英语不好，你的代码永远看起来不专业。

书籍涵盖的主题从个人责任、职业发展，知道用于使代码保持灵活、并且易于改编和复用的

各种架构技术。

总结起来方法有三：平时多练手，多阅读优秀的源码，阅读优秀的编程技巧类型的书。

⑺ 如果在开发项目中，一个插件用了两次，修改bug时要改插件的源码该怎么办

第一种是面向过程思想写的分页插件中的代码，第二种是面向对象思想写的分页插件中的代码，思想不同，但改的两种方法都同时适用以上的分页插件！改插件最主要是看懂它的思路，然后顺其自然就很容易了！ps：建议看不懂的以后可以多打开各种插件和框架源码看，多思考，相信你会学到更多

⑻ java编程时显示错误需要class,interface或enum怎么解决

推荐下载ide!!!!!!

此代码诸多错误

publicstaticvoidmain0(String[]args){
Scannerin=newScanner(System.in);
System.out.println("MSG:1");
intsex=in.nextInt();
switch(sex){
case1:
System.out.println("石头");
break;
case2:
System.out.println("剪刀");
break;
case3:
System.out.println("布");
break;
default:
System.out.println("请重新输入");
break;
}
}

⑼ 微信的bug怎么修复

首先，你要定位 bug。这时，你需要：

1.注重逻辑性。不要做没有证据的结论。如果你有猜测，就去证实或者否定它。比如某次，同事代码返回的数据有问题，认为是缓存用的 Redis 有问题，返回了错误的数据。然而没人去对此猜测进行求证……我去确认了一下，Redis 收到了请求，并且响应正常。接下来，排除所有其它可能的原因之后，最后剩下的那个就是真相。真相就是，代码里有个 } 的位置放错了，因为它刚好在一屏之后的位置，所以没有人发现……（是 Vim 帮我找到的）

2.基本的方法论。比如二分法。比如最小化测试用例。如果你要提问，要懂得提问的智慧，不管是向搜索引擎还是向人，你都需要提出正确的问题。

3.知识面。你写 Web 后端的话，普通的 HTTP 得懂，浏览器的开发者工具得会用。简单的 JavaScript 也有会点儿。简单地说就是，你要精于你自己主攻的部分，然后要熟悉你的上下游。再比如如果你使用 CPython 的话，你要准备一份 CPython 的源码，并且要能够流畅地阅读 C 代码。

4.工具。工欲善其事，必先利其器。一大堆调试用的工具，你至少得知道它们能干什么，需要的时候能用。比如 strace、lsof、gdb、git bisect，还有高级点的 sysdig、systemtap、perf 等等。当然还有一堆不是专门为调试而设计的通用工具，比如 the silver searcher 或者 ripgrep。一个快速的全文搜索工具能帮你在最短时间内找到相关的代码或者日志。你不必成为正则表达式大师，但是简单的一定要会，不然面对上千个匹配结果你要怎么办呢？Vim 有一个插件 Mark，能够同时高亮多个模式，非常利于调试期间阅读代码和日志。投入时间学习使用高效的工具，不要把时间浪费在等待和人工搜索上，也不要让自己忙于琐事而断了灵感和线索。

最后，不要不断地、毫无目的地换个环境啦，换个版本啦，换个用户啦，这样子找问题。如果这样做很有效的话，大家都去买彩票去了。

找到 bug 之后，理解它是如何产生的。当你理解之后才能真正修好它。就像你感冒了吃抗生素，根本没有用。

⑽ 看起来是线程池的BUG，但是我认为是源码设计不合理

前几天看到一个 JDK 线程池的 BUG，我去了解了一下，摸清楚了它的症结所在之后，我觉得这个 BUG 是属于一种线程池方法设计不合理的地方，而且官方在知道这个 BUG 之后表示：确实是个 BUG，但是我就不修复了吧，你就当这是一个 feature 吧。

在带你细嗦这个 BUG 之前，我先问一个问题：

这玩意，老八股文了，存在的时间比我从业的时间都长，得张口就来：

这次的这个 BUG 触发条件之一，就藏着在这个 DiscardPolicy 里面。

但是你一去看源码，这个玩意就是个空方法啊，这能有什么 BUG？

它错就错在是一个空方法，把异常给静默处理了。

别急，等我慢慢给你摆。

BUG 对应的链接是这个：

标题大概就是说：噢，我的老伙计们，听我说，我发现线程池的拒绝策略 DiscardPolicy 遇到 invokerAll 方法的时候，可能会导致线程一直阻塞哦。

然后在 BUG 的描述部分主要先注意这两段：

这两段透露出两个消息：

所以我们还得先去这个 BUG 最先出现的地方看一下。也就是这个链接：

从标题上来看，这两个问题非常的相似，都有 invokerAll 和 block，但是触发的条件不一样。

一个是 DiscardPolicy 拒绝策略，一个是 shutdownNow 方法。

所以我的策略是先带你先把这个 shutdownNow 方法嗦明白了，这样你就能更好的理解 DiscardPolicy 带来的问题。

本质上，它们说的是一回事儿。

在 shutdownNow 相关的这个 BUG 描述里面，提问者给到了他的测试用例，我稍微改改，就拿来就用了。

代码贴在这里，你也可以那到你本地跑一下：

然后给大家解释一下测试代码是在干啥事儿。

首先标号为 ① 的地方，是往 list 里面塞了 10 个 callable 类型的任务。

搞这么多任务干啥呢？

肯定是要往线程池里面扔，对吧。

所以，在标号为 ② 的地方，搞了一个线程和核心线程数是 2 的线程池。在线程里面调用了线程池的 invokerAll 方法：

这个方法是干啥的？

执行给定的任务集合，在所有任务完成后返回一个包含其状态和结果的 Futures 列表。

也就是说，当线程启动后，线程池会把 list 里面的任务一个个的去执行，执行完成后返回一个 Futures 列表。

我们写代码的时候拿着这个列表就能知道这一批任务是否都执行完成了。

但是，朋友们，但是啊，注意一下，你看我的案例里面根本就不关心 invokerAll 方法的返回值。

关心的是在 invokerAll 方法执行完成后，输出的这一句话：

好，现在你来说这个程序跑起来有什么毛病？

你肯定看不出来对不对？

我也看不出来，因为它根本就没有任何毛病，程序可以正常运行结束：

接着，我把程序修改为这样，新增标号为 ③ 的这几行代码：

这里调用的是线程池的 shutdown 方法，目的是想等线程池把任务处理完成后，让程序退出。

来，你又说说这个程序跑起来有什么毛病？

你肯定又没有看不来对不对？

我也没有，因为它根本就没有任何毛病，程序可以正常运行结束：

好，接下来，我又要开始变形了。

程序变成这样：

注意我这里用的是 shutdownNow 方法，意思就是我想立即关闭前面的那个线程池，然后让整个程序退出。

那么这个程序有什么问题呢？

它是真的有问题，肉眼真不好看出来，但是我们可以先看一下运行结果：

结果还是很好观察的。

没有输出 “invokeAll returned”，程序也没有退出。

那么问题就来了：你说这是不是 BUG ？

咱先不管原因是啥，从现象上看，这妥妥的是 BUG 了吧？

我都调用 shutdownNow 了，想的就是立马关闭线程池，然后让整个程序退出，结果任务确实是没有执行了，但是程序也并没有退出啊，和我们预期的不符。

所以，大胆一点，这就是一个 BUG！

再来一个关于 shutdownNow 和 shutdown 方法输出对比图，更直观：

至于这两个方法之间有什么区别，我就不讲了，你要是不知道就去网上翻翻，背一下。

反正现在 BUG 已经能稳定复现了。

接下来就是找出根因了。

根因怎么找呢？

你先想想这个问题：程序应该退出却没有退出，是不是说明还有线程正在运行，准确的说是还有非守护线程正在运行？

对了嘛，想到这里就好办了嘛。

看线程堆栈嘛。

怎么看？

照相机啊，朋友们。我们的老伙计了，之前的文章里面经常露面，就它：

你就这么轻轻的一点，就能看到有个线程它不对劲：

它在 WAITING 状态，而导致它进入这个状态的代码通过堆栈信息，一眼就能定位到，就是 invokeAll 方法的 244 行，也就是这一行代码：

既然问题出在 invokeAll 这个方法里面，那就得理解这个方法在干啥了。

标号为 ① 的地方，是把传入进来的任务封装为一个 Future 对象，先放到一个 List 里面，然后调用 execute 方法，也就是扔到线程池里面去执行。

这个操作特别像是直接调用线程池的 submit() 方法，我给你对比一下：

标号为 ② 的地方，就是循环前面放 Future 的 List，如果 Future 没有执行完成，就调用 Future 的 get 方法，阻塞等待结果。

从堆栈信息上看，线程就阻塞在 Future 的 get 方法这里，说明这个 Future 一直没有被执行。

为什么没有被执行？

好，我们回到测试代码的这个地方：

10 个任务，往核心线程数是 2 的线程池里面扔。

是不是有两个可以被线程池里面的线程执行，剩下的 8 个进入到队列里面？

好，我问你：调用 shutdownNow 之后，工作线程是不是直接就给干没了？剩下的 8 个是不是没有资源去执行了？

话说回来，哪怕只有 1 个任务没有被执行呢？invokeAll 方法里面的 future.get() 是不是也得阻塞？

但是，朋友们，但是啊，就在 BUG 如此清晰的情况下，上面的这个案例居然被官方给推翻了。

怎么回事呢？

带你看一下官方大佬的回复。

哦，对不起，不是大佬，是官方巨佬 Martin 和 Doug 的回复：

Martin 说：老铁，我看了你的代码，感觉没毛病啊？你听我说，shutdownNow 方法返回了一个 List 列表，里面放的就是还没有被执行任务。所以你还得拿着 shutdownNow 的返回搞一些事情才行。

Doug 说：Martin 说的对。额外说一句：

they 指的就是这个 list。也就是说老爷子写代码的时候是考虑到这个情况了的，所以把没有执行的任务都返给了调用者。

好吧，shutdownNow 方法是有返回值的，我之前居然没有注意到这个细节：

但是你仔细看这个返回值，是个 list 里面装的 Runnable，它不是 Future，我就不能调用 future.cancel() 方法。

所以拿到这个返回值之后，我应该怎么取消任务呢？

这个问题问得好啊。因为提问者也有这样的疑问：

他在看到巨佬们说要对返回值做操作之后，一脸懵逼的回复说：哥老倌些，shutdownNow 方法返回的是一个List。至少对我来说，我不知道应该这么去取消这些任务。是不是应该在文档里面描述一下哦？

Martin 老哥觉得这个返回确实有点迷惑性，他做了如下回复：

线程池提交任务有两种方式。

如果你用 execute() 方法提交 Runnable 任务，那么 shutdownNow 返回的是未被执行的 Runnable 的列表。

如果你用 submit() 方法提交 Runnable 任务，那么会被封装为一个 FutureTask 对象，所以调用 shutdownNow 方法返回的是未被执行的 FutureTask 的列表：

也就是说 shutdownNow 方法返回的 List 集合，里面装的既可能是 Runnable，也可能是 FutureTask，取决于你往线程池里面扔任务的时候调用的什么方法。

FutureTask 是 Runnable 的子类：

所以，基于 Martin 老哥的说法和他提供的代码，我们可以把测试用例修改为这样：

遍历 shutdownNow 方法返回的 List 集合，然后判断是否 Future，如果是则强转为 Future，接着调用其 cancel 方法。

这样，程序就能正常运行结束。

这样看来，好像也确实不是一个 BUG，可以通过编码来避免它。

但是，朋友们，但是啊，前面都是我的铺垫，接下来剧情开始反转了。

我们回到这个链接中：

这个链接里面提到了 DiscardPolicy 这个线程池拒绝策略。

只要我稍微的把我们的 Demo 程序改变一点点，触发线程的 DiscardPolicy 拒绝策略，前面这个 bug 就真的是一个绕不过去的 bug 了。

应该怎么改变呢？

很简单，换个线程池就可以了：

把我们之前这个核心线程数为 2，队列长度无限长的线程池替换为一个自定义线程池。

这个自定义线程池的核心线程数、最大线程数、队列长度都是 1，采用的线程拒绝策略是 DiscardPolicy。

其他的地方代码都不动，整个代码就变成了这样，我把代码贴出来给你看看，方便你直接运行：

然后我们先把程序运行起来看结果：

诶，怎么回事？

我明明处理了 shutdownNow 的返回值呢，怎么程序又没有输出 “invokeAll returned” 了，又阻塞在 invokeAll 方法上了？

就算我们不知道为什么程序没有停下来，但是从表现上看，这玩意肯定是 bug 了吧？

接下来我带你分析一下为什么会出现这个现象。

首先我问你在我们的案例里面，这个线程池最多能容纳几个任务？

是不是最多只能接收 2 个任务？

最多只能接收 2 个任务，是不是说明我有 8 个任务是处理不了的，需要执行线程池的拒绝策略？

但是我们的拒绝策略是什么？

是 DiscardPolicy，它的实现是这样的，也就是静默处理，丢弃任务，也不抛出异常：

好，到这里你又接着想，shutdownNow 返回的是什么东西，是不是线程池里面还没来得及执行的任务，也就是队列里面的任务？

但是队列里面最多也就一个任务，返回回来给你取消了也没用。

所以，这个案例和处不处理 shutdownNow 的返回值没有关系。

关键的是被拒绝的这 8 个任务，或者说关键是触发了 DiscardPolicy 拒绝策略。

触发一次和触发多次的效果都是一样的，在我们这个自定义线程池加 invokeAll 方法这个场景下，只要有任何一个任务被静默处理了，就算玩蛋。

为什么这样说呢？

我们先看看默认的线程池拒绝策略 AbortPolicy 的实现方式：

被拒绝执行之后，它是会抛出异常，然后在 invokeAll 方法里面会被捕捉到，所以不会阻塞：

如果是静默处理，你没有任何地方让这个被静默处理的 Future 抛出异常，也没用任何地方能调用它的 cancel 方法，所以这里就会一直阻塞。

所以，这就是 BUG。

那么针对这个 BUG，官方是怎么回复呢？

Martin 巨佬回复说：我觉得吧，应该在文档上说明一下，DiscardPolicy 这个拒绝策略，在真实的场景中很少使用，不建议大家使用。要不，你把它当作一个 feature？

我觉得言外之意就是：我知道这是一个 BUG 了，但是你非得用 DiscardPolicy 这个不会在实际编码中使用的拒绝策略来说事儿，我觉得你是故意来卡 BUG 的。

我对于这个回复是不满意的。

Martin 老哥是有所不知，我们面试的时候有一个八股文环节，其中的一个老八股题是这样的：

如果有一些大聪明，在自定义线程池拒绝策略的时候，写出了一个花里胡哨的，但是又等效于 DiscardPolicy 的拒绝策略。

也就是又没放进队列，又没抛出异常，不管你代码写的多花哨，一样的是有这个问题。

所以，我觉得还是 invokeAll 方法的设计问题，一个不能在调用线程之外被其他线程访问的 Future 就不应该被设计出来。

这违背了 Future 这个对象的设计理念。

所以我才说这是 BUG，也是设计问题。

什么，你问我应该怎么设计？

对不起，无可奉告。