单例 多例

 
单例
每一次请求同一个变量--内存地址是同一个
spring 默认是单例的 可以配置scope="prototype"改成多例
优点:不用每次都开辟新的内存空间
 
缺点:当遇到并发请求的时候,值会冲突 混乱 覆盖,报错(全局变量)
 
多例
 
每一次请求都是一个新的变量 --新的内存地址影响:当遇到并发请求的时候,值不会出现冲突,覆盖等问题struts2默认多例优点:当遇到并发请求的时候,值不会冲突 混乱
 
缺点:虽然每次请求开辟新的空间,=但对应会消耗一定内存模拟单例
 
ssh框架中,可以把action设成单例模式,然后使用增加功能,第一次增加在保存数据库之前打断点(不要继续调用保存,可以输出对象的内存地址看看)
 
然后增加第二条数据也会定位到断点(也不进行继续保存,在输出内存对象地址看看,会发现和第一次请求一样)两次请求,变量的内存地址一样,这就是单例模式
 
影响:走完断点,保存到数据库的两条数据,都是第二次填写的数据!!!!
模拟多例
 
与单例一样的操作,不过你会发现,两次变量的内存地址是不一样的即便定位断点,那么数据库的值也是正确的 这就是多以
 
 
 
 
hibernate 和 jdbc区别是什么?
 
持久层框架作用?
 
把数据持久化到数据库区别:
 
hibernate 全自动 开发效率高执行效率低 jdbc 全手动 开发效率地执行效率高
 
实现同一个查询功能 jdbc 实现查询:加载驱动--获得链接--编译sql--执行返回结果集---循环封装List ---关闭链接
 
过程较多 代码繁琐执行:
 
直接执行sql 不需要任何转换hibernate实现查询: 相关配置文件完成后--》 定义 查询hql 执行返回list
 
过程简单 代码简洁执行:
 
hql最终转换成sql去执行执行完之后 自动封装成对应的实体类同样的功能 jdbc 过程较多 代码繁琐
 
hibernate 过程简单 代码简洁结论,hibernate 开发效率高 jdbc 开发效率低 jdbc : 直接执行sql 不需要任何转换 hibernate : 转sql 封装数据
结论:hibernate 执行效率低 jdbc 执行效率高
 
jdk jre 区别
jdk(通过bin下的 javac 和 java命令)
 
能编译java文件能运行class
 
jre(通过bin下的java命令)只能运行class
 
不能编译java jdk包含jre
保存的时候 编译成class ctrl+s
浏览器请求 是定位的哪里的class?tomcat


main请求 定位项目里的class文件
### 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、付费专栏及课程。

余额充值