发表于： 2017-12-28 19:09:42
4 686
编辑日报内容.
4.为什么要用Log4j来替代System.out.println？
1.背景介绍
记录日志可以作为日后处理问题的一个追溯，方便开发者根据日志来统计查询处理问题。此外，查阅日志内容可以了解项目的运行状况，发现项目存在的一些隐藏的bug。
2.知识剖析
Log4j是什么?
Log4j 是Apache的一个开放源代码项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件、甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是，这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。
此外，通过Log4j其他语言接口，您可以在 C、C++、.Net、PL/SQL程序中使用Log4j，其语法和用法与在Java程序中一样，使得多语言分布式系统得到一个统一一致的日志组件模块。而且，通过使用各种第三方扩展，您可以很方便地将Log4j集成到J2EE、JINI甚至是SNMP应用中。
3.常见问题
Log4j的特点
可以轻松的控制log信息是否显示、log信息的输出端类型、输出方式、输出格式，更加细致地控制日志的生成过程，而其通过配置文件可以灵活的进行配置而不需要大量的更改代码。
4.解决方案
为什么要用Log4j来替代System.out.println
1. Log4j就是帮助开发人员进行日志输出管理的API类库。它最重要的特点就可以配置文件灵活的设置日志信息的优先级、日志信息的输出目的地以及日志信息的输出格式。
2. Log4j除了可以记录程序运行日志信息外还有一重要的功能就是用来显示调试信息。
3. 程序员经常会遇到脱离java ide环境调试程序的情况，这时大多数人会选择使用System.out.println语句输出某个变量值的方法进行调试。这样会带来一个非常麻烦的问题：一旦哪天程序员决定不要显示这些System.out.println的东西了就只能一行行的把这些垃圾语句注释掉。若哪天又需调试变量值，则只能再一行行去掉这些注释恢复System.out.println语句。
使用log4j可以很好的处理类似情况。
15.什么是贫血模型，什么是充血模型？为什么我们会强制要求使用贫血模型？
领域模型是领域内的概念类或现实世界中对象的可视化表示，又称为概念模型或分析对象模型，它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。贫血模型是指使用的领域对象中只有setter和getter方法（POJO），所有的业务逻辑都不包含在领域对象中而是放在业务逻辑层。有人将我们这里说的贫血模型进一步划分成失血模型（领域对象完全没有业务逻辑）和贫血模型（领域对象有少量的业务逻辑），我们这里就不对此加以区分了。充血模型将大多数业务逻辑和持久化放在领域对象中，业务逻辑（业务门面）只是完成对业务逻辑的封装、事务和权限等的处理。贫血模型和充血模型的分层架构。更加细粒度的有失血模型，贫血模型，充血模型，胀血模型。贫血模型就是domain ojbect包含了不依赖于持久化的领域逻辑，而那些依赖持久化的领域逻辑被分离到Service层。失血模型简单来说，就是domain object只有属性的getter/setter方法的纯数据类，所有的业务逻辑完全由business object来完成(又称Transaction Script)，这种模型下的domain object被Martin Fowler称之为“贫血的domain object”。充血模型和第二种模型差不多，所不同的就是如何划分业务逻辑，即认为，绝大多业务逻辑都应该被放在domain object里面(包括持久化逻辑)，而Service层应该是很薄的一层，仅仅封装事务和少量逻辑，不和DAO层打交道。
贫血模型：是指领域对象里只有get和set方法，或者包含少量的CRUD方法，所有的业务逻辑都不包含在内而是放在Business Logic层。
优点是系统的层次结构清楚，各层之间单向依赖，Client->(Business Facade)->Business Logic->Data Access(ADO.NET)。当然Business Logic是依赖Domain Object的。似乎现在流行的架构就是这样，当然层次还可以细分。
该模型的缺点是不够面向对象，领域对象只是作为保存状态或者传递状态使用，所以就说只有数据没有行为的对象不是真正的对象。在Business Logic里面处理所有的业务逻辑，在POEAA(企业应用架构模式)一书中被称为Transaction Script模式。
充血模型：层次结构和上面的差不多，不过大多业务逻辑和持久化放在Domain Object里面，Business Logic只是简单封装部分业务逻辑以及控制事务、权限等，这样层次结构就变成Client->（Business Facade)->Business Logic->Domain Object->Data Access。
优点是面向对象，Business Logic符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重。
缺点是如何划分业务逻辑，什么样的逻辑应该放在Domain Object中，什么样的业务逻辑应该放在Business Logic中，这是很含糊的。即使划分好了业务逻辑，由于分散在Business Logic和Domain Object层中，不能更好的分模块开发。熟悉业务逻辑的开发人员需要渗透到Domain Logic中去，而在Domian Logic又包含了持久化，对于开发者来说这十分混乱。 其次，因为Business Logic要控制事务并且为上层提供一个统一的服务调用入口点，它就必须把在Domain Logic里实现的业务逻辑全部重新包装一遍，完全属于重复劳动。
16.Spring中的IOC是什么意思，为什么要用IOC而不是New来创建实例？
Ioc—Inversion of Control，即“控制反转”
Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制
下面我们来讲讲Ioc的底层实现原理
主要用到的有以下几种技术
(1)xml配置文件
(2)dom4j解析xml文件
(3)工厂设计模式
(4)反射
public class Factory(
//返回类对象的方法
public static User getUser(){
//1.使用dom4j解析文件
//根据第一步配置的id值得到所对应的class的值
String classValue="class属性值"
//2.通过反射创建类的对象
Class class= Class.forName(classValue);
//创建类对象
User user = class.newInstance();
return user;
})
属性注入的三种方法
(1)set方法注入
(2)有参构造方法注入
(3)接口注入
3. 常见问题
(1)IOC有哪些缺点？
(2)IOC和DI有什么不同之处？
(3)控制反转是控制什么反转?
(4)依赖注入,谁依赖谁,注入了什么?
4. 解决方案
(1)通过反射来创建对象，会造成效率上的损耗，但是相对IOC的优点灵活性和可维护性来说不值一提，并且缺少IDE重构的支持，如果修改了类名，需要到xml文件里手动修改
(2)其实是一会事，只是强调的内容不同。IOC控制反转，强调容器的作用，用于组织或控制容器内bean的运行。DI依赖注入，强调Bean需要外部注入才能正常运转。
(3)它把传统上由程序代码直接操控的对象的调用权交给容器
(4)依赖注入就是把有依赖关系的类放入IOC容器中，然后解析出这个类的实例
17.为什么要使用Interface，而不是直接使用一个实体类来完成任务？Interface和Impl这种方式的好处是什么？
接口是什么？
Java接口是一系列方法的声明，是一些方法特征的集合，一个接口只有方法的特征没有方法的实现，因此这些方法可以在不同的地方被不同的类实现，而这些实现可以具有不同的行为
二、知识剖析
先来看看接口的特点：
1、Java接口中的成员变量默认都是public,static,final类型的(都可省略),必须被显示初始化,即接口中的成员变量为常量(大写,单词之间用"_"分隔)
2、Java接口中的方法默认都是public,abstract类型的(都可省略),没有方法体,不能被实例化
3、Java接口中只能包含public,static,final类型的成员变量和public,abstract类型的成员方法
4、接口中没有构造方法,不能被实例化
5、一个接口不能实现(implements)另一个接口,但它可以继承多个其它的接口
6、Java接口必须通过类来实现它的抽象方法
7、当类实现了某个Java接口时,它必须实现接口中的所有抽象方法,否则这个类必须声明为抽象类
8、不允许创建接口的实例(实例化),但允许定义接口类型的引用变量,该引用变量引用实现了这个接口的类的实例
9、一个类只能继承一个直接的父类,但可以实现多个接口,间接的实现了多继承.
三、常见问题
为什么要使用接口？
偶然在知乎上看到的疑惑：
我定义了一个接口，但是我在继承这个接口的类中还要写接口的实现方法，那我不如直接就在这个类中写实现方法岂不是更便捷，还省去了定义接口
四、解决方案
接口的优点与作用
1. 接口是个规范
2. 接口进行了抽象
3. 实现多态.
18.为什么要处理异常，Try/Catch应该在什么样的场景下使用，在真实的系统中，会出现网络中断，DB连接不上的错误吗？多久会发 生一次？
try/catch是java程序员经常用的程序块，怎么用，什么时候catch异常，什么时候抛出异常？用不好，程序可能会有致命性错误。
使用的基本原则
对异常的处理，两种方式，一是添加 throws exceptions，向上抛出，交由方法的调用方处理该异常；二是使用try/catch块，捕捉异常，自己处理。
选择哪种方式，取决于异常应该怎么处理。
使用抛出异常的情景主要有：
1. 异常必须由容器来处理，异常时容器做出不同处理的依据和触发；
例如：有事务处理的方法中，事务相关的逻辑必须抛出异常，而不能捕获异常，否则会导致事务不回滚。
2. 本地方法不知道如何处理，只有调用方才可能知道如何处理异常；
例如：一些底层的方法，其可能出现多种异常，且调用方可能根据不同的异常做出不同的处理，只能抛出异常，而且必须是具体的异常类型，而不能是笼统的Exception类型。
使用try/catch捕获异常的情景主要有：
1. 程序块中语句可能的异常不能引起其他逻辑中断；
例如：缓存逻辑不能影响正常的逻辑运行，故缓存逻辑应该放在try/catch块中。
2. 必须对异常进行处理，否则会降低用户使用体验。
例如：异常到了Controller层，若不处理则会返回404或500错误页面，因此，必须使用try/catch处理各种异常。
如果出现DB断开---->一般是开销太大才会DB断开,一般很少发生
19.日志应该怎么打，在什么位置，需要打印出来什么样的关键参数？
模块运行日志：模块运行日志包括消息队列的监控、线程的运行状态。该日志应该以INFO级别打印，并且采用间隔打印，或叫做定时打印。以减少日志打印总量。从该角度可以反应出该模块是否有消息队列积压，是否所有线程都运行正常。消息队列的打印可以采用日下格式：
使用统一的关键字Monitor来标示模块运行日志。队列监控日志使用|队列名|消息放入速度|消息取出速度|消息放入个数|消息取出个数|当前队列消息个数|。线程监控日志使用|线程名|线程状态码|，线程状态码可以自己扩展。0表示正常1表示运行结束2表示线程阻塞。
业务日志：业务日志打印用户请求流程，能够清楚的使用某几个关键字可以提取一个用户的业务流程就可以。业务日志要分详细日志，如上BossAgent打印的日志，非常详细，应该都打印DEBUG级别的日志，而另外就需要打印总结性日志，总结性日志以INFO级别打印，包括|请求开始时间|请求结束时间|请求主体|请求类型|请求结果|请求外部资源返回结果|。其中请求主体可以继续扩展，如BossAgent的请求主体可以扩展为|手机号码|省份编码|MM2消息SEQUENCE|，DSS的请求主体可能属性更多一些，|手机号码|手机密码|手机UA|手机MOD|手机MAN|计费类型|套餐类型|白名单|。
模块性能日志：模块的性能日志应该能够通过该日志清晰的反应该模块目前性能，包括外部请求的压力，内部请求处理速度。
模块外部资源日志：模块的外部资源日志需要详细记录，现今单独的模块很少见了，很多大型复杂的系统往往是由多个模块构成，模块间采用或标准或私有协议进行通信。这种场景下爆发的问题往往比较复杂，并且与多个模块都有关系或是责任。所以在模块级别上将该模块所依赖的外部资源都打印出来非常重要，通过这些日志应该能够完成快速定位问题与哪些模块相关联或是哪些模块需要负根本责任。通常模块的外部资源包括数据库，系统间内部模块、第三方系统。如BossAgent的外部资源包括数据库，系统间内部模块为PSS、第三方系统应该是一级Boss。数据库资源的打印应该包括所有的SQL语句，这个非常重要，无论是问题的定位还是后续的SQL优化，还是数据库架构的调整，都需要这些信息能够快读的整理出该模块所有的SQL语句，提供给专业的DBA进行分析。SQL语句的打印还应该包括参数的打印。
20.为什么需要单步调试？Debug的时候IDE是怎么找到源码的？
单步调试可以更好的找到错误的地方,还有获取的值是否有获取到,单步的调试看得到每个变量的值的获取,还有对应值的变化
这个ide原码----->还不知道怎么弄后面的学到---->在来慢慢的解决
21.可否远程连接到线上直接调试？真实的项目中，遇到问题的排查方案是什么？
1、背景介绍
我们一般在本地写代码时，如果程序出现问题了，一般情况下，我们会在程序中打各种log，调试，找出问题，修改，测试，部署到服务器，再测试。但如果在真实项目中的呢，这样做虽然也可以，显然是不方便的。
真实项目中，我们可以通过远程连接的方式，进行调试
远程调试：服务端程序运行在一台远程服务器上，我们可以在本地服务端的代码（前提是本地的代码必须和远程服务器运行的代码一致）中设置断点，每当有请求到远程服务器时时能够在本地知道远程服务端的此时的内部状态。
2、知识剖析
在本次课程中将涉及以下4点内容
1.服务器
2.项目部署到服务器
3.本地的IED连接远程
4.调试
3、常见问题
本地IDE如何连接到远程进行调试，需要配置什么？
远程的端口的配置---->连接到远程的服务器
开始主要是看数据库的链接还有tomcat的运行是不是正常,还有是不是服务器端的承载量不够,修改缓冲的数据库连接池的数量,
还在就是项目中的查看日志的打印的异常的位置在哪里----->这样解决问题的方式要快一些
昨天的任务日报有写一下深度思考的问题,还没有看完,今天看了一下,自己还有很多没有了解----->加油坚持
..
返回列表
评论