容器

Spring 核心技术

爱⌒轻易说出口 提交于 2020-03-08 14:30:59
核心技术 版本 5.2.4.RELEASE 参考文档的这一部分涵盖了Spring框架中不可获取的所有技术 其中最重要的是Spring的ioc(控制反转)容器,在对SpringIOC进行了全面的处理之后,还对SpringAOP技术进行了全面的介绍。Spring框架有它自己的AOP框架,并且在概念上容易理解,成功的解决了Java企业编程中AOP需求的80%功能点。 Spring还提供了对AspectJ的支持。 1 IOC容器 这一章覆盖了SpringIOC容器 1.1 介绍SpringIOC容器和bean 这一章覆盖了Spring框架实现了IOC容器的原理。IOC也成为依赖注入(DI)。这是一个对象仅通过构造函数参数、工厂方法的参数或对象实例构造或从工厂方法返回后在对象实例上设置的属性来定义其依赖项(即与之一起工作的其他对象)的过程。然后容器在创建bean时注入这些依赖项。这个过程基本上是bean本身的逆过程(因此成为控制反转),通过使用类的直接构造或一种机制(如服务定位器模式)来控制依赖项的实例化或位置。 这org.springframework.beans 和 org.springframework.context包是SpringIOC容器的基础。BenaFactory接口提供了能够管理任何类型对象的高级配置机制。ApplicationContext是BeanFactory的子接口

Kubernetes 新时代的宠儿

非 Y 不嫁゛ 提交于 2020-03-08 13:17:47
本文首发于我的公众号 Linux云计算网络(id: cloud_dev) ,专注于干货分享,号内有 10T 书籍和视频资源,后台回复 「1024」 即可领取,欢迎大家关注,二维码文末可以扫。 Kubernetes 是什么 Kubernetes 简称为 K8S。简单说,K8S 是一个用于容器集群的分布式系统架构。首先,它是基于容器技术,容器是和虚拟机并列的一种虚拟化技术,相比虚拟机来说,容器更加轻量,资源利用率更高,是微服务化的宠儿,更适合于云原生应用。 其次,K8S 掌管的是容器集群,就像它的名字一样,一个舵手指挥着一个个的集装箱航行。容器会被频繁地销毁、重建和调度,为了最大化地利用集群资源和减少人力成本,K8S 在其中以高效的策略,自动化的运维方式指挥着这一切,就像一台永动机一样,管理员可以一劳永逸。 最后,K8S 的架构非常开放,分布式的组件结构,使得它可以轻松地适应大规模的集群环境,Google 庞大的数据中心就是它最好的历练。 为什么 K8S 能赢? 随着 2014 年 Docker 大火之后,已经涌现出大量的容器集群管理平台,其中,Docker 自家的 Swarm,在 Twitter 内部久经考验的 Mesos,以及 Google 的 K8S 最为知名,号称容器编排三驾马车。下图是三家的热度走势图: K8S 自诞生日起便一骑绝尘,甩对手十几条街。为什么 K8S 能赢

java中为什么要使用迭代器

孤者浪人 提交于 2020-03-08 12:23:00
简而言之,集合的遍历如果用for来进行的话,需要知道集合的内部构造,想遍历数组的时候一样,需要索引有序。但是例如set集合是无序的,使用for遍历不了。这时需要迭代器来遍历,把集合中所有的元素都找出来。 迭代器(Iterator)模式,又叫做游标(Cursor)模式。迭代器提供一种对容器对象中的各个元素进行访问的方法,而又不需暴露该对象的内部细节。 从定义可见,迭代器模式是为容器而生。 很明显,对容器对象的访问必然涉及到遍历算法。你可以将遍历方法写到容器对象中去(内部迭代器);或者根本不去提供什么遍历算法,让使用容器的人自己去实现去吧(外部迭代器)。这两种情况好像都能够解决问题。 然而在前一种情况,容器承受了过多的功能,它不仅要负责自己“容器”内的元素维护(添加、删除等等),而且还要提供遍历自身的接口;而且由于遍历状态保存的问题,不能对同一个容器对象同时进行多个遍历。第二种方式倒是省事,却又将容器的内部细节暴露无遗。 而迭代器模式的出现,很好的解决了上面两种情况的弊端。 由于迭代器模式本身的规定比较松散,所以具体实现也就五花八门。我们先来列举下迭代器模式的实现方式。 1.迭代器角色定义了遍历的接口,但是没有规定由谁来控制迭代。在Java collection的应用中,是由客户程序来控制遍历的进程,被称为外部迭代器; 还有一种实现方式便是由迭代器自身来控制迭代,被称为内部迭代器。

spring依赖注入和控制反转

烈酒焚心 提交于 2020-03-08 09:23:22
2017-11-15 学习过Spring框架的人一定都会听过Spring的IoC(控制反转) 、DI(依赖注入)这两个概念,对于初学Spring的人来说,总觉得IoC 、DI这两个概念是模糊不清的,是很难理解的,今天和大家分享网上的一些技术大牛们对Spring框架的IOC的理解以及谈谈我对Spring Ioc的理解。 一、分享Iteye的开涛对Ioc的精彩讲解 首先要分享的是Iteye的开涛这位技术牛人对Spring框架的IOC的理解,写得非常通俗易懂,以下内容全部来自原文,原文地址:http://jinnianshilongnian.iteye.com/blog/1413846 1.1、IoC是什么 Ioc—Inversion of Control,即“控制反转”,不是什么技术,而是一种设计思想。 在Java开发中, Ioc意味着将你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制。 如何理解好Ioc呢?理解好Ioc的关键是要明确“谁控制谁,控制什么,为何是反转(有反转就应该有正转了),哪些方面反转了”,那我们来深入分析一下: ●谁控制谁,控制什么:传统Java SE程序设计,我们直接在对象内部通过new进行创建对象,是程序主动去创建依赖对象;而IoC是有专门一个容器来创建这些对象,即由Ioc容器来控制对 象的创建; 谁控制谁?当然是IoC 容器控制了对象;控制什么

依赖注入和控制反转

谁说我不能喝 提交于 2020-03-08 09:03:04
热 1 吴鹏建 2010-07-26 12:20 [顶]3G移动--Android开发工程师全能班 看到一个对这个概念很好诠释的帖子,特转发过来供大家一起学习 转载地址 http://www.iteye.com/topic/692793 IoC——Inversion of Control 控制反转 DI——Dependency Injection 依赖注入 要想理解上面两个概念,就必须搞清楚如下的问题: 参与者都有谁? 依赖:谁依赖于谁?为什么需要依赖? 注入:谁注入于谁?到底注入什么? 控制反转:谁控制谁?控制什么?为何叫反转(有反转就应该有正转了)? 依赖注入和控制反转是同一概念吗? 下面就来简要的回答一下上述问题,把这些问题搞明白了,IoC/DI也就明白了。 (1)参与者都有谁: 一般有三方参与者,一个是某个对象;一个是IoC/DI的容器;另一个是某个对象的外部资源。 又要名词解释一下,某个对象指的就是任意的、普通的Java对象; IoC/DI的容器简单点说就是指用来实现IoC/DI功能的一个框架程序;对象的外部资源指的就是对象需要的,但是是从对象外部获取的,都统称资源,比如:对象需要的其它对象、或者是对象需要的文件资源等等。 (2)谁依赖于谁: 当然是某个对象依赖于IoC/DI的容器 (3)为什么需要依赖: 对象需要IoC/DI的容器来提供对象需要的外部资源 (4

web.xml的简单解释以及Hello1中web.xml的简单分析

微笑、不失礼 提交于 2020-03-08 03:32:14
一、web.xml的加载过程 ①当我们启动一个WEB项目容器时,容器包括(JBoss,Tomcat等)。首先会去读取web.xml配置文件里的配置,当这一步骤没有出错并且完成之后,项目才能正常的被启动起来。 ②启动WEB项目的时候,容器首先会去读取web.xml配置文件中的两个节点:<listener> </listener>和<context-param> </context-param>。 ③紧接着,容器创建一个ServletContext(application),这个web项目的所有部分都将共享这个上下文。 容器以 <context-param></context-param>的 name作为键, value作为值,将其转化为键值对,存入 ServletContext。   ④在容器创建 <listener></listener>中的类实例,根据配置的 class类路径 <listener-class>来创建监听, ⑤ 接着,容器会读取 <filter></filter>,根据指定的类路径来实例化过滤器。 ⑥如果系统中有 Servlet,则 Servlet是在第一次发起请求的时候被实例化的,而且一般不会被容器销毁,它可以服务于多个用户的请求。所以, Servlet的初始化都要比上面提到的那几个要迟。 二、标签 ①<web-app></web-app> <web-app><

Java与C ++中的哈希

余生颓废 提交于 2020-03-07 20:06:59
Java和C ++在语法上有些相似,但是随着时间的流逝而发生了变化。Java受到C ++的宽松启发,但最初并未采用C ++的模板结构,也不需要C ++的头文件/内容文件分离,并且当然,它使用JVM并编译为字节码而不是机器码。 从那时起,这两种语言在某种程度上融合了起来-它们遵循相似的编码准则,支持Lamda构造,泛型/模板,循环语法的多个相同形式,等等。但是,现代用途肯定存在差异。C ++模板支持专业化,而Java泛型支持类型限制。它们也具有相似的基本集合类型。 哈希表,哈希图和类似类型的数据结构,这些数据结构允许通过唯一键进行索引,但是该索引是以非常特定的方式实现的。现在,任何关联的容器类型都可以让你通过特定键访问数据。例如,你可以使用链表作为存储结构,也可以使用双链表或二叉树。哈希表本质上使用数组,但是该数组由哈希值索引。 Java 具有作为类的基本关联容器类型 java.util.HashMap 。 C ++ 有 std::unordered_map 。 基于哈希的容器在数据存储方面具有明显的优势。当使用具有低冲突可能性的哈希生成器时,两个容器( HashMap 和 unordered_map )都具有 O ( 1 )查找性能。碰撞的可能性越大,容器的性能就越接近 O ( n ),其中 n 是存储在容器中的元素数。这两个容器也都使用标准的哈希函数 -Java 需要键来实现

二、容器

安稳与你 提交于 2020-03-07 19:56:43
java容器有哪些 数组、String(底层是char数组)、java.util下 的 List、Set、Map、Queue,画图说明如下: Collection和Collections有什么区别 Collection为集合的通用接口,提供了对集合进行操作的通用接口方法 Collections为集合操作的工具类,提供了集合的静态操作方法,不能实力化 List、set、Map之间的区别是什么 三个集合操作的不同 HashMap和HashTable有什么区别 HashMap:线程不安全,效率高;key和value可以为空 HashTable:线程安排,效率低;key和value都不能为空 如何决定使用HashMap还是TreeMap HashMap不支持排序,查询效率高;TreeMap默认用key排序,也支持自定义排序,查询效率低;如无排序要求,尽量使用HashMap HashMap的实现原理 利用key的hashCode重新hash计算出当前对象的元素在数组中的下标 存储时,如果没有该hash值得key,则放入;如果出现hash值相同的key,此时有两种情况。(1)如果key相同,则覆盖原始值;(2)如果key不同(出现冲突),则将当前的key-value放入链表中 获取时,直接找到hash值对应的下标,在进一步判断key是否相同,如果相同,取出该值;如果不同,从链表中找对应值。

04-使用docker容器

坚强是说给别人听的谎言 提交于 2020-03-07 16:27:08
Docker容器 docker容器是另一个核心概念,容器是镜像的一个运行实例。不同的是镜像是静态的只读文件,容器带有运行时需要的可写层,并且容器中的应用进程处于运行状态。 虚拟机是模拟运行一整套操作系统,docker只运行一个应用和它的运行环境。 创建容器 新建容器,docker [container] create命令新建的容器处于停止状态 [root@docker01 ~]# docker create -it ubuntu:18.04 550c14d7db29b3fbcdff0819546403779f8ce717fa2a5012909b057c2f8b1806 [root@docker01 ~]# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 550c14d7db29 ubuntu:18.04 "/bin/bash" 34 seconds ago Created kind_rosalind 启动容器,docker [container] start命令来启动一个已经创建的容器 [root@docker01 ~]# docker start 55 55 [root@docker01 ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED

docker 嵌套技术 docker outside of docker 可用于一个容器内调用另一个容器内程序 跨容器调用

|▌冷眼眸甩不掉的悲伤 提交于 2020-03-07 10:48:56
环境:centos7 docker升级为最新版, docker升级方法参考:《centos7 docker升级到最新稳定版本》 https://blog.csdn.net/whatday/article/details/104612681 以tomcat容器为例: docker run --name web --privileged -v /etc/localtime:/etc/localtime:ro -v /var/run/docker.sock:/var/run/docker.sock -v /usr/bin/docker:/usr/bin/docker -d -p 8080:8080 tomcat:8.5.35 重点: 1.将宿主机 /var/run/docker.sock 文件挂载到容器,实现容器内 docker 操作宿主机 docker 的目的 2.将宿主机 /usr/bin/docker 文件挂载到容器,直接当docker客户端使用。 宿主机docker列表: tomcat容器内docker列表: 可以看到完全一样, 此时可以在 tomcat 容器中调用 其他容器 内的程序,示例如下: docker exec 其他容器 /bin/bash -c 'cd /packages/detectron && python tools/train.py' 注意事项: 1.-it