Java程序报错问题分析

2019-12-04

听说..

佛曰: 前世五百年的回眸,才换来今生的擦肩而过
程序员: 佛祖上辈子我造了碰到了谁?这辈子必须每天都见一次bug
佛曰: 尔等没有前生,为后世集福吧

Java程序报错问题分析:

一定要看错误, 根据错误查找问题 !!!

有错误先找错误, 没错误就使用debug

当你发现如果所有的其他地方都没有问题的时候,要把那些你认为一定没问题的代码重新怀疑一遍

雪崩时, 没有一片雪花是无辜的

1.1 编译时报错

编译不通过– 根据控制台错误找问题

1) interface ,或者common 层开发了新的方法,新的接口,但是没有安装导致编译不通过,可能是其他模块尚未编译,虽然idea预编译时不会报错, 但当进行编译时, maven引入了其他模块的坐标, 而其它模块更改之后并没有重新编译打包, 那么maven引用的还是未修改之前的版本, 重新clear install即可

2) 代码的某一行导入了不该导入的包(可能这个包根本就没有用到)

此时控制台会报告那个类的哪一行可能import了错误的类,找到修改就好了

3) pom文件导入报错

我们从PDF 文档中copy 过来的坐标有时候有特殊不可见字符字符 , 碰到这类问题我们要记住: 不要从pdf 中复制坐标,从老师的代码中复制

1.2 静态网页报错,效果不显示

方法1) 根据错误查找原因: 打开开发者模式

F12是个好东西

方法2) 二分法

先删一半代码, 看有没有解决, 没有解决再删一半代码

如果正常了一定是刚删的代码的问题

能快速定位错误代码的位置, 节约时间

1.3 vue id not defined

var app = new vue(){} //小写

var app2 = new Vue(){}

1.4 ConnectException

如果服务启动是报错,此时应该根据错误日志定位问题

找到我们能看懂的关键词

java.net.ConnectException: Connection refused: no further informatiion

at org.apache.zookeeper.ClientcnxnsocketNIO.doTransport

可能是zookeeper没有启动, 或者启动失败, 重启一下试试

1.5 404问题

打开控制台查看请求路径

确认html路径是否有误,大小写, 空格等

web-xml是否配置spring-mvc

web.xml 中拦截路径没有写成写成*.do

包扫描是否有误

没有加上@Responsebody注解

方法上我们使用的是RestController 注解,但是我们看到的却是 Controller 注解

1.6 空指针异常

user.getUsername(); 一定是.之前的user为空

如果是 servcie 对象,可能是没有 @Reference ,或者 @Reference 注解导入包错误了

如果是 Controller层的参数问题,则有可能是前端传递的参数和我们Controller 层接收的参数不一致

1.7 No provider available

没有提供者, 服务器端出现问题

没加@Service(interfaceClass = exampleService.class)

@Service 注解上是否忘记了 interfaceclass 配置

unimplemented interface : exampleService.class是否写错, 复制来的需要更改

包扫描是否有误

1.8 Could not find result map com.syx.pojo.User

userMapper映射文件中resultType写成了resultMap

1.9 集群, 分布式和负载均衡

集群：同一个业务，部署在多个服务器上。集群主要是简单加机器解决问题，对于问题本身不做任何分解；

主要的使用场景是为了分担请求的压力，也就是在几个服务器上部署相同的应用程序，来分担客户端请求。

分布式：一个业务拆分为多个子业务，部署在多个服务器上。

将一套系统拆分成不同子系统部署在不同服务器上（这叫分布式），然后部署多个相同的子系统在不同的服务器上（这叫集群），部署在不同服务器上的同一个子系统应做负载均衡。

负载均衡（Load Balance）：其实就是将请求分摊到多个操作单元上进行执行，从而共同完成工作任务。

在集群负载均衡时，Dubbo 提供了多种均衡策略（包括随机、轮询、最少活跃调用数、一致性Hash），缺省为random随机调用。

配置负载均衡策略，既可以在服务提供者一方配置，也可以在服务消费者一方配置，如下:

@Controller
@RequestMapping("/demo")
public class HelloController {
    //在服务消费者一方配置负载均衡策略
    @Reference(check = false,loadbalance = "random")
    private HelloService helloService;

    @RequestMapping("/hello")
    @ResponseBody
    public String getName(String name){
        //远程调用
        String result = helloService.sayHello(name);
        System.out.println(result);
        return result;
    }
}

//在服务提供者一方配置负载均衡
@Service(loadbalance = "random")
public class HelloServiceImpl implements HelloService {
    public String sayHello(String name) {
        return "hello " + name;
    }
}

可以通过启动多个服务提供者来观察Dubbo负载均衡效果。

注意：因为我们是在一台机器上启动多个服务提供者，所以需要修改tomcat的端口号和Dubbo服务的端口号来防止端口冲突。

在实际生产环境中，多个服务提供者是分别部署在不同的机器上，所以不存在端口冲突问题。

本文作者： 夏虫语冰
发布时间： 2019-12-04
最后更新： 2019-12-04
本文标题： Java程序报错问题分析
本文链接： https://shiyongxu.github.io/2019/12/04/Java程序报错问题分析/
版权声明： 本作品采用 CC BY-NC-SA 4.0 许可协议进行许可。转载请注明出处！