单例多例

本文详细介绍了单例和多例模式的概念及其在软件开发中的应用。解释了单例适用于无状态对象,有助于减少资源消耗;而多例用于处理有状态对象,避免并发问题。并提供了在Spring框架下实现这两种模式的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

单例多例需要搞明白两个问题:
1. 什么是单例多例;
2. 如何产生单例多例;
3. 为什么要用单例多例
4. 什么时候用单例,什么时候用多例;
1. 什么是单例多例:
所谓单例就是所有的请求都用一个对象来处理,比如我们常用的service和dao层的对象通常都是单例的,而多例则指每个请求用一个新的对象来处理,比如action;
2. 如何产生单例多例:
在通用的SSH中,单例在spring中是默认的,如果要产生多例,则在配置文件的bean中添加scope="prototype";
3. 为什么用单例多例:
之所以用单例,是因为没必要每个请求都新建一个对象,这样子既浪费CPU又浪费内存;
之所以用多例,是为了防止并发问题;即一个请求改变了对象的状态,此时对象又处理另一个请求,而之前请求对对象状态的改变导致了对象对另一个请求做了错误的处理;
用单例和多例的标准只有一个:
当对象含有可改变的状态时(更精确的说就是在实际应用中该状态会改变),则多例,否则单例;
4. 何时用单例?何时用多例?
对于struts2来说,action必须用多例,因为action本身含有请求参数的值,即可改变的状态;
而对于STRUTS1来说,action则可用单例,因为请求参数的值是放在actionForm中,而非action中的;
另外要说一下,并不是说service或dao一定是单例,标准同第3点所讲的,就曾见过有的service中也包含了可改变的状态,同时执行方法也依赖该状态,但一样用的单例,这样就会出现隐藏的BUG,而并发的BUG通常很难重现和查找;

java单例解析,单例vs多例

什么是单例:一个对象只有一个实例,这个对象自行提供这个实例服务于整个系统。
什么是多例:一个对象不但但只有一个实例,想要多少有多少。
1、特点
单例:无状态、只有一个实例
多例:有状态、多个实例
2、使用场景
必须是无状态的&&(工具类的||初始化消耗大资源类的)
比如数据库操作类,单例实例化时初始化连接池,以后就是操作数据库的工具类,不再重新初始化数据库连接池
另外举个spring的例子,spring是使用单例的大户,dao和service都是使用单例,而且默认bean也都是单例,
spring使用单例就是把这些单个实例的bean拼成了一个大的工具盒,方便我们用哪个取哪个。
3、单例实现方式
单例有两种实现方式,学名是饿汉式和懒汉式。
饿汉式在类加载时初始化,懒汉式是在第一次获取实例时初始化。
在web应用中我认为使用饿汉式会更合适,系统一启动单例就初始化完成,
有请求了立马可以提供服务,web应用还是效率更重要嘛。
### Docker 中模式与多例模式的区别及应用场景 #### 模式的概念及其特点 在软件设计中,模式是一种常见的设计模式,它确保某一个类仅有一个实,并提供全局访问点。对于 Docker 而言,虽然其本身并未直接定义“”这一概念,但在实际应用中可以通过某些方式实现类似的行为。如,在容器编排工具(如 Kubernetes 或 Docker Compose)中,通过配置文件指定某个服务运行一副本的方式可以视为一种模式的应用[^1]。 这种模式的主要特点是: - **唯一性**:在整个系统生命周期内,该服务始终只有一个活跃的实。 - **资源共享**:多个客户端请求均指向同一个服务实,从而减少资源消耗并提升效率。 - **性能优化**:由于减少了重复创建和销毁操作,能够有效降低开销,特别是在高并发环境下表现尤为明显。 #### 多例模式的概念及其特点 相对应于模式,“多例”则允许同一类型的服务存在多个独立实。在 Docker 的上下文中表现为启动多个相同的容器镜像实来分担负载或者增强冗余度以保障业务连续性。比如在一个分布式架构里部署 Web 应用程序时通常会采用这种方式——即水平扩展技术。 此类方法具备如下特性: - **弹性伸缩能力**:依据实时流量动态调整工作节点数量;既可以在高峰期增加处理元又能在低谷期缩减规模节省成本。 - **容错机制加强**:即使部分服务器出现问题也不会影响整体服务质量因为还有其他备用选项可用。 #### 两者之间的区别对比表 | 特征/维度 | 模式 | 多例模式 | |------------------|---------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------| | 实数目 | 整个应用程序范围内保持唯一的实 | 可拥有任意数量的不同实 | | 并发支持情况 | 对所有线程共享数据结构的操作必须同步保护以免引发竞争条件 | 各自维护自己的状态空间所以不存在上述顾虑 | | 初始化时机 | 提前加载至内存以便随时调用 | 按需触发 | | 使用场景举说明 | 数据库连接池管理器、日志记录设施等 | 微服务体系下的各个微服务模块 | #### 场景分析 ##### 模式适用场合 当希望保证特定功能逻辑在整个系统中有且仅有一次执行路径的时候适合选用此方案。如: - 配置中心:集中存储各类参数设置供下游消费方读取更新而无需担心版本冲突等问题; - 缓存代理层:统一对外暴露接口屏蔽底层复杂细节同时兼顾高效检索需求; - 日志收集端口监听者角色承担起汇聚来自不同源头的消息职责进而持久化保存起来便于后续审计追踪之用等等情形皆可考虑引入设计理念加以解决[^3]。 ##### 多例模式典型运用领域 而对于那些强调横向扩容潜力以及高度可靠性的任务来说,则更倾向于采纳多例策略来进行规划布局。具体而言包括但不限于以下几个方面: - API网关集群建设旨在分流外部来访压力并通过健康检测剔除异常成员维持正常运转秩序; - 计算密集型作业分配给分布在多地数据中心里的计算引擎共同协作完成大规模科学运算挑战; - 存储阵列组建过程中为了满足海量非结构化资料存放诉求往往也会采取类似的思路构建庞大的物理设备集合体作为支撑底座[^2]。 ```python import docker client = docker.from_env() # 创建模式示 singleton_container = client.containers.run('nginx', detach=True, name='my-singleton-container') # 创建多例模式示 replicated_containers = [] for i in range(3): # 假设我们需要三个副本 container_name = f'my-replica-{i}' replicated_containers.append(client.containers.run('nginx', detach=True, name=container_name)) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值