ioc

基于xml的ioc案例 结构图 一、pom.xml导坐标 < packaging > jar < / packaging > < dependencies > < ! -- spring的坐标 -- > < dependency > < groupId > org . springframework < / groupId > < artifactId > spring - context < / artifactId > < version > 5.0 .2 . RELEASE < / version > < / dependency > < ! -- dbutils的坐标 -- > < dependency > < groupId > commons - dbutils < / groupId > < artifactId > commons - dbutils < / artifactId > < version > 1.7 < / version > < / dependency > < ! -- mysql驱动坐标 -- > < dependency > < groupId > mysql < / groupId > < artifactId > mysql - connector - java < / artifactId > < version > 8.0 .17 <

循环依赖问题 什么是循环依赖 首先看一下下面的Spring配置文件 <!-- beanA依赖于beanB --> <bean id="beanA" class="top.okay3r.ClassA"> <property name="beanB" ref="beanB"/> </bean> <!-- beanB依赖于beanA --> <bean id="beanB" class="top.okay3r.ClassB"> <property name="beanA" ref="beanA"/> </bean> 当IOC容器读取上面的配置时，就会先对beanA进行加载；在对beanA进行属性填充时，会发现beanA依赖于beanB，然后就会对beanB进行加载；当对beanB进行属性填充时，又会发现beanB依赖于beanA，于是就加载beanA… 可以想到，如果Spring的容器对于这种循环依赖问题不作出响应的处理，那么就会无限执行上面的过程。最终的结果就可能造成OOM从而导致程序崩溃 Spring中bean注入的方式 我们知道在Spring中，注入bean的方式有【构造器注入】和【setter注入】两种方式。但在我们使用Spring管理bean时，可能会遇到一种特殊的情况，那么就是上面所说的循环依赖问题 我们再看一下Spring创建bean的过程 Spring创建bean的过程

随着net的深入学习，出现了很多概念性的东西需要理解，现在统一记录一下。 1.依赖：现阶段在任何一个有请求作用的系统，都会出现A类调用B类的情况，这时候A类就依赖于B类，A类和B类存在依赖关系。 2.耦合、解耦：A类依赖于B类，这时对B类调用，一般通过A a=new B();的形式，不过这个时候如果B类重构(例如：增加了一个参数param1)，要保证A类的正确使用，则必须重新new：A a=new B(param1); 则此时A类和B类就是耦合关系。不过带来了很多的不方便之处，如果B类频繁变动，则A类也必须同步修改，所以这时候想到了解耦（即解除这种关系，B类变动A类不用处理，交给其他类处理）。 3.IOC（ Inversion of Control 控制反转）：有控制反转，应该也有控制 ‘正转’ 吧，可以用网上查到的一个形象例子说明：“我”充当一个入口类，在这个入口类中，我每次去吃饭都需要 主动 去买一双一次性筷子（每次使用都需要new一次），让筷子乖乖的到我手里来，是“我”控制了筷子。不过呢，在现实生活中，大部分人都是很懒的，我完全可以买一双精致的筷子放到容器中(IOC)中，每次要调用时，就向容器请求，容器通过“注入"的方式给我一双筷子，这个过程中，“我”就变为了请求方，而容器变为了控制方，控制关系发生了 反转。 4.DI（ Dependency Injection 依赖注入 ）

平常的java开发中，程序员在某个类中需要依赖其它类的方法，则通常是new一个依赖类再调用类实例的方法，这种开发存在的问题是new的类 实例不好统一管理，spring提出了依赖注入的思想，即依赖类不由程序员实例化，而是通过spring容器帮我们new指定实例并且将实例注入到需要该 对象的类中。依赖注入的另一种说法是“控制反转”，通俗的理解是：平常我们new一个实例，这个实例的控制权是我们程序员，而控制反转是指new实例工作 不由我们程序员来做而是交给spring容器来做。 spring有多种依赖注入的形式，下面仅介绍spring通过xml进行IOC配置的方式： Set注入 这是最简单的注入方式，假设有一个SpringAction，类中需要实例化一个SpringDao对象，那么就可以定义一个private的SpringDao成员变量，然后创建SpringDao的set方法（这是ioc的注入入口）： Java代码 package com.bless.springdemo.action; public class SpringAction { //注入对象springDao private SpringDao springDao; //一定要写被注入对象的set方法 public void setSpringDao(SpringDao springDao) { this

1.为什么要学习spring？ 1.1设计理念和目标 首先要了解spring的设计理念和目标，可以这么说，spring为开发者提供的是一个 一站式的轻量级应用开发框架 （平台），作为平台，spring抽象了我们 在许多应用开发中遇到的共性问题，同时，作为一个轻量级的应用开发框架，spring和传统的J2EE开发相比，有其自身的特点，通过这些自身的特点 充分体现了它的设计理念： 在java EE的应用开发中，支持POJO和使用JavaBean的开发方式，使应用面向接口开发，充分支持OO（面向对象）的设计方 式 。 比如，在java EE应用开发中，传统的EJB开发需要依赖按照J2EE规范实现的J2EE应用服务器，我们的应用在设计，特别是实现时，往往需要一系列的接口标 准 才能够在应用服务器的环境中得到测试和部署，这种开发方式，使应用在可测试性和部署上都会受到一些影响，spring的设计理念采用了相对EJB而言的 轻量级开发思想，即使用POJO的开发方式，只需要使用简单的java对象或者JavaBean就能进行Java EE开发，这样开发入门，测试，应用部署都得到了简化 另一方面，在我们的应用开发中，往往会涉及复杂的对象耦合关系，如果在java代码中处理这些耦合关系，对代码的维护性和应用扩展性会带来很多不便 而如果使用spring作为应用开发平台，通过使用spring的IOC容器

@[toc] 1. Spring注解的源码分析 1.1 我如何开始分析源码的？ 这一部分可以略过直接看第1.2节 想必程序员都会经过这样一个阶段，当 一门编程语言的语法 已经能够熟练运用。并且它的 流行框架 也能够用到 五分熟 ，程序员就会找进阶的入口，这时候就想到了去了解源码。 作为Java程序员，首先想到的一定是了解Spring源码，但是Spring这个东西庞然大物，从哪里开始都是个问题！这时候我就想起了唐曾那句话：“贫僧从东土大唐而来，往西天取经而去”。真的很羡慕他，知道自己从哪来，还知道自己该往哪去。这样的人已经不多了。那么对Spring源码的剖析该从哪来呢？ 我经历过这几个阶段： 网上看视频（像B站里有很多好的关于spring源码的视频，但是视频有个缺点就是如果忘记了，想复习一遍，没那么容易。） 看网上的博客，这就不用说了。网上的博客五花八门，鱼龙混杂，想要找到一篇适合自己的很不容易。（放弃了） 啃书本，最开始我看的是《Spring源码深度剖析》，但这本书打着Spring5的旗号，讲解xml的内容，作为跟进潮流的程序员表示，我想看关于注解方式的源码解析。然后我又看了《Spring揭秘》《Spirng 技术内幕》等等。没有一本是符合自己的。 黄天不负有心人，最终我还是找到了一本合适的书籍《Spring5 核心原理——手写Spirng 30 个类实战》不得不说

依赖注入与控制反转 依赖注入 当我第一次接触这个词的时候，我是有些丈二和尚摸不着头脑的，至今我也是感到比较困惑的，所以今天我们来探索一下Laravel中的 依赖注入(dependency injection) , 来好好的理解它。 控制反转 第一印象是好深奥的名词。。。看上去好像是说反向控制？不懂？那就理顺之！ 起点 什么是依赖 没有你我就活不下去，那么，你就是我的依赖。 说白了就是： 不是我自身的，却是我需要的，都是我所依赖的。一切需要外部提供的，都是需要进行依赖注入的。 我们用代码来描述一下： class Boy { protected $girl; public function __construct(Girl $girl) { $this->girl = $girl; } } class Girl { ... } $boy = new Boy(); // Error; Boy must have girlfriend! // so 必须要给他一个女朋友才行 $girl = new Girl(); $boy = new Boy($girl); // Right! So Happy! 从上述代码我们可以看到 Boy 强依赖 Girl 必须在构造时注入 Girl 的实例才行。 那么为什么要有 依赖注入 这个概念， 依赖注入 到底解决了什么问题？

Spring-理解IOC容器 序言 IoC粗理解 IoC细理解 Spring中IoC的应用 IoC容器 容器的两种表现形式 BeanFactory的IoC实现过程： IoC容器初始化过程 BeanDefinition的定位 BeanDefinition的载入 IoC容器的依赖注入 IoC小结 参考文章： 序言 IoC(Inversion of Control) 控制反转，两种实现： 依赖查找（DL） 依赖注入（DI） IoC包括 依赖查找(DL) 和 依赖注入(DI) ；只不过DL因为有 侵入性 (它需要用户自己去是使用 API 进行查找资源和组装对象)，已经被抛弃。所以现在提到IoC，更多的想到的就是依赖注入(DI)了。 依赖注入(DI)包括Set注入和构造器注入！其实还有一个通过实现接口的方式实现依赖注入，不过不常用，就不说了。 注意：Java 使用 DI 方式实现 IoC 的不止 Spring，包括 Google 的 Guice，还有一个冷门的 PicoContainer（极度轻量，但只提供 IoC）。 如图所示： 但其实 IOC 和DI 相当于一回事，只不过是看待问题的角度不同而已: IOC: Spring 反向控制应用程序需要的资源。 DI: 应用程序依赖Spring为其提供资源。 IOC 是站在Spring 的角度，而DI 是站在应用程序的角度。 如下图所示：

简要的做一些spring-mvc部分的源码学习笔记 Spring-mvc做的工作主要是俩大方面吧：一个是初始化一个ioc容器，一个是mvc部分的控制和视图模块的实现。 先说下ioc容器的初始化部分：ioc的初始化主要在俩个地方，一个是contextLoadListener里，另一个在DispatcherServlet里。 contextLoadListener： 在contextLoadListener里初始化的ioc容器是整个web项目里的一个父容器。整个初始化的过程也比较简单，首先是实例化一个context，具体是哪个context类呢，我们可以在web.xml的配置里指定，不过我们一般也不会指定这个参数，所以就直接实例化了一个默认的context-XmlWebApplicationContext。实例化以后，就开始加载我们配置文件里的那些bean。配置文件的位置我们一般都在web.xml里进行了配置。具体的加载的过程都在refresh（）方法里。 这refresh方法里我们一般比较关心的是不同类型的bean的注册的过程还有实例化的过程。具体的注册过程就不再说了。 在注册完成后，会首先实例化一些ioc关心的bean，比如各种processor，还有一些特定类型的bean，具体可以细看下代码。然后会把实例化后的一些在ioc容器里有特定功能的bean进行注册

Hibernate工作原理及为什么要用? 原理： 1.通过Configuration().configure();读取并解析hibernate.cfg.xml配置文件 2.由hibernate.cfg.xml中的<mapping resource="com/xx/User.hbm.xml"/>读取并解析映射信息 3.通过config.buildSessionFactory();//创建SessionFactory 4.sessionFactory.openSession();//打开Sesssion 5.session.beginTransaction();//创建事务Transation 6.persistent operate持久化操作 7.session.getTransaction().commit();//提交事务 8.关闭Session 9.关闭SesstionFactory 为什么要用： 1. 对JDBC访问数据库的代码做了封装，大大简化了数据访问层繁琐的重复性代码。 2. Hibernate是一个基于JDBC的主流持久化框架，是一个优秀的ORM实现。他很大程度的简化DAO层的编码工作 3. hibernate使用Java反射机制，而不是字节码增强程序来实现透明性。 4. hibernate的性能非常好，因为它是个轻量级框架。映射的灵活性很出色。它支持各种关系数据库