internal server error？

解决方法：

1、服务器日常维护

进行停机处理，或者更新程序，这时候，浏览者登陆该网站，就会报500的错误，一般等维护更新完毕，启动服务器以后，就可以自动解决，用户只需要耐心等待即可。

2、程序bug

当程序员编写的程序不够严谨，出现异常的时候，浏览者也会看到500的错误，解决这种问题的方法是，联系程序开发人员，进行程序跟踪，debug下程序，找到错误所在，然后修改程序，经测试没有问题，重新发布程序，然后系统正常。

3、中毒引起

有的时候，有写病毒会改写服务器的一些设置，导致用户无法正常访问，报500的错误，这时需要程序员进行杀毒处理，处理完程序后，系统恢复正常。

4、配置问题

有的时候，用户无法访问网站，是因为系统参数的配置有问题，遇到这种情况，找BASIS人员进行处理，处理完毕，访问就正常了。

5、数据库问题

网站读写 *** 作都在数据库，数据库如果异常的话，睁首访问也会不正常，遇到此类情况，通知网站的DBA，让他帮助分析解决，解决完毕后，访问就会正常。

“internal server error”原因：

这个问题不是浏览者造成的，而是你所浏览的服务器出现了故障哗早搜，一般来讲乱历，如果对这种错误不加处理的话，会显示一堆乱麻，有经验的程序员，一般认为的控制这种错误，一般的话，显示该网站正在维护，或者此页无法显示。

BUG，“程序错误；漏洞”的意思，修复BUG，即为：修复漏洞、修复程序。

Bug，是程序设计中的术语，是指在软件运行中因为程序本身有错误而造成的功能不正常、死机、数据丢失、非正常中断等现象。有些程序错误会造成计算机安全隐患，此时叫做漏洞。有严重后果的程序错误会受到广泛关注。修补、改正软件程序错误的过程被称为调试。

一些有趣的隐错桥州有时也会成为一种乐趣。在单机（也有网络游戏）游戏中，假如一些隐错不令游戏出现大错误，经常会变成一种玩游戏时的秘技，玩家会运用这些BUG当做是秘籍来使用，在网络游戏出现BUG的时候，官方会第一时间行卖修复，因为会影响游戏平衡，严重的话，官方会封禁利用BUG的玩家。

扩展资料：

名称由来——

为马克2号（Harvard Mark II）编制程序的葛丽丝·霍波（Grace Hopper）是一位美国海军准将及计算机科学家，同时也是世界最早的一批程序设计师之一，有一天，她在调试设档消逗备时出现故障，拆开继电器后，发现有只飞蛾被夹扁在触点中间，从而“卡”住了机器的运行。

于是，霍波诙谐的把程序故障统称为“臭虫（BUG）”，把排除程序故障叫DEBUG，而这奇怪的“称呼”，竟成为后来计算机领域的专业行话。

参考资料来源：百度百科-BUG

事情的起因是微服务A通过feign调用微服务B的某个接口，报了形如下的异常

负责微服务A的工程师小张就找到负责提供该接口的工程师小李，问小李是不是改动了接口，小李一脸无辜说他最近没对这个接口做任何改动，不过小李还是说道他排查一下。

小李排查的过程如下，他先通过swagger查看他提供给A服务接口是否存在，他一查发现他在swagger上看不到他提供给A服务的接口。于是他怀疑是不是有人动了他的代码，他就去查找最近的git提交记录，发现没人动他的代码，因为项目还没发布，都在测试阶段，他就根据项目集成的git-commit-id-maven-plugin插件定位到测试目前发布具体是哪个版本。（ps：对

git-commit-id-maven-plugin感兴趣的朋友，可以查看之前的文章聊聊如何验证线上的版本是符合预期的版本）。然后他将该版本的代码下到本地进行调试，他发现代码中提供给A的接口还在，target下的class也有提供给A的接口class，但诡异的是swagger就是没显示他提供出去的接口，他一度以为是swagger出了问题，于是他用postman直接请求他提供A的接口，发现报了404。然后他就叫负责同个微服务B的同事小王，也帮忙试一下，发现结果就是404。后面没招，小李就去求助他们项目资深同事小林。

小林的排查思路如下，他先走查一下小李的接口代码，发现他提供的接口实现层的方法上加了一个@Async，示例形如下

小林凭多年的经验直觉告诉小李说，应该是@Async引起。小李很斩钉截铁的说不可能啊，他@Async很早就加了，之前接口都可以访问的，小林一看小李说得那么肯定，他也不好打击小李。于是他接下来做了如下兄滑森 *** 作，先在项目中yml配置如下参数，开启springweb日志

然后在项目中加了形如下代码，来跟踪接口bean的类型

启动控制台，看日志形如下

发现确实没打印出相关requestMapping映射信息，这可以说明一点就是小李那个接口没有绑定到springmvc映射，也就是出现404的原因。接着观察控制台打印的bean，内容形如下

这很明显这个接口bean已经被jdk动态代理给替换。小李看到控制台打印的信息，若有所思，然后说，我把@Async去掉试下。小李把@Async去掉后，再观察下控制台

通过控制台可以发现，此时接口已经绑定到springmvc映射，而且打印出bean类型是真实对象bean。小李看到这个现象，也百思不得其解，他说道他之前确实是加了@Async，接口也能正常访问。于是小林就问一句，你确定你加了@Async，异步生效了吗，小李说开启spring异步，不都是加@Async吗。小林又问了一句，你在项目中开启异步，除了加@Async，还有做什么处理吗，小李说没了，他之前在项目使用异步就都是加了@Async，也能用了好好的，小林一听，基本上知道为什么小李之前@Async，接口还能正常访问了，小林为了验证想法，就问同负责该项目的小王，说你最近有加什么异步 *** 作吗，小王说有，小林进一步问，你是怎么做的，小王说，他先加@EnabledAsyn，开启异步，然后在业务逻辑层上的方法上加@Async注解。小李一听，说原来使用@Async还要配合@EnabledAsyn啊，他之前都不知道

接着小李说羡亩 那在controller是不是就不能使用@Async注解了？ ，小林说最好是把加@Async的逻辑挪到service层去处理，不过也不是controller就不能使用@Async注解了，接着小林为了验证这个想法，他把原来实现的接口类去掉，形如下

启动后，查看控制台

此时bean的类型如下

访问接口，打印内容如下

从控制台可以发现，都是http-nio-8080-exec-1线程触发，说明异步没生效，即@Async失效。后面对controller做了如下改造

访问接口，打印内容如下

这说明在controller其实也是可以用@Async，只是要额外做处理。让喊所以建议是把@Async从controller中抽离出去，在新类中进行处理，示例如下

访问接口，打印内容

说明异步生效

从mvc日志

我们可以知道，controller映射处理是在RequestMappingHandlerMapping 这个类中，但具体是哪个方法进行处理呢，我们可以通过日志打印的信息，进行倒推，也可以基于spring的特性加断点调试，比如通过afterPropertiesSet这一启动扩展点调试起，就会发现RequestMappingHandlerMapping的映射处理是在

进行处理，具体是通过processCandidateBean进行处理

最终是通过detectHandlerMethods进行处理

这个里面就是做了实际注册。而执行detectHandlerMethods的前提是

即只有加了@Controller或者@RequestMapping的类会进行处理，而@RestController为啥也处理，点击

@RestController发现

他本质就是@Controller。但我们通过反射查找注解，正常只会查找一层，比如

他找到@RestController这一层，而不会找继续再找@RestController里面的@Controller，而AnnotatedElementUtils.hasAnnotation，这个注解方法就不一样，他是可以找到合并注解，即使是使用

@RestController，他还会继续找到里面的@Controller。因此这个方法对于找复合型注解很有用

当我们使用jdk动态代理时，因为父类上没加@Controller或者@RequestMapping，因此他不会被mvc进行映射处理，导致404。而使用cglib时，因为他是作为子类继承了目标类，因此他会继承目标类上的注解，因此当为cglib代理时，他会正常被mvc进行映射处理

这是因为加了@Async后，controller变成代理了，而当要异步处理方法，用this时，他使用的是目标对象，而非代理对象。这跟现在面试事务为啥事务失效的八股文基本是一个套路

本文主要讲@Async导致controller 404，同时也使@Async失效的原因。解决的推荐方法就是将@Async抽离出controller，新建一个service类进行处理。

---