盘扣式脚手架该怎样进行搭建和拆除?有啥技术要求呢?
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了盘扣式脚手架该怎样进行搭建和拆除?有啥技术要求呢?相关的知识,希望对你有一定的参考价值。
参考技术A盘扣式脚手架用于模板支架施工中,脚手架搭设与拆除是如何规定:模板支架立杆搭设位置应按专项施工方案放线确定。模板支架搭设应根据立杆防止可调底座,应按先立杆后水平杆再斜杆的顺序搭设,形成基本的架体单元,因以此基本单元扩展,搭设成整体支架体系。可调底座和土层基础上垫板应准确放置在定位线上,保持水平。垫板应平整、无翘曲、不得采用以开裂垫板。盘扣式脚手架立杆应通过立杆连接套管连接,在同一水平高度内,相邻立杆连接套管接头的位置宜错开,且错开高度不小于500mm。盘扣式脚手架的水平杆扣接头与连接盘的插销应用铁锤击紧,(最好专门派人挨个检查,锤击一遍)。每搭设完一步支模架后,应及时校正水平杆步距,立杆的纵、横距,立杆的垂直偏差和水平杆的水平偏差。立杆的垂直偏差不应大于模板支架总高度的1/500,且不得大于50mm。在多层楼板上连续设置盘扣式脚手架模板支架时,应保证上下层支撑立杆在同一轴线上。混凝土浇筑前,施工管理人员应组织对搭设的盘扣式脚手架支架进行验收,并应确认符合专项施工方案要求后浇筑混凝土。盘扣式脚手架拆除作业应按先搭后拆,后搭先拆的原则,从顶层开始,逐层向下进行,严禁上下同时拆除,严禁抛掷。分段、分立面拆除时,应确定分界处的技术处理方案,并应保证分段后架体稳定。
参考技术B落地式双排承插型盘扣钢管脚手架搭设的立杆纵距为1.50m,横距为0.9m,步距为1.50m,脚手架的连墙件竖向间距为3.0m,水平间距为4.50m,操作平台满铺脚手板。脚手架上下爬梯采用定型挂扣式钢梯,平台满铺钢制脚手板,架体设在左右幅墩柱中间,梯步、休息平台宽度0.9m,楼梯长1.8,高1.5m,基础按脚手架要求处理,通道护身栏杆:上部高1.2m,中部高0.6米,下设0.18m高挡脚板,梯步护手高0.9m,爬梯与架体同步搭设。盘扣式脚手架宜使用同一标高的梁板底板的标高范围,对于高度和跨度较大的单一构件支承架使用时对横杆进行拉力和立杆轴向压力(临界力)的验算,确保架体的稳定性和安全性;架体搭设完成后要加设足够的剪刀撑,在顶托与架体横杆300-500mm之间的距离要增设足够的水平拉杆,使其整体稳定性得到可靠的保证。
参考技术C搭拆脚手架,应设置警戒区,并派专人警戒。遇有六级以上大风和恶劣气候,应停止脚手架搭拆工作。对地基的要求,地基不平时,请使用可掂底座脚,达到平衡。地基必须有承受脚手架和工作时压强的能力。工作人员搭建和高空工作中必须系有安全带,工作区域周边请安装安全网,防止重物掉落,砸伤他人。脚手架的构件、配件在运输、保管过程中严禁严重摔、撞;搭接、拆装时,严禁从高处抛下,拆卸时应从上向下按顺序操作。使用过程注意安全,严禁在架上打闹嬉戏,杜绝意外事故发生。工作固然重要,安全、生命更加重要,请务必牢记以上内容。
对于单例模式面试官会怎样提问呢?你又该如何回答呢?
欢迎关注公众号【Ccww技术博客】,原创技术文章第一时间推出
前言
在面试的时候面试官会怎么在单例模式中提问呢?你又该如何回答呢?可能你在面试的时候你会碰到这些问题:
为什么说饿汉式单例天生就是线程安全的?
传统的懒汉式单例为什么是非线程安全的?
怎么修改传统的懒汉式单例,使其线程变得安全?
线程安全的单例的实现还有哪些,怎么实现?
双重检查模式、Volatile关键字 在单例模式中的应用
ThreadLocal 在单例模式中的应用
枚举式单例
那我们该怎么回答呢?那答案来了,看完接下来的内容就可以跟面试官唠唠单例模式了
单例模式简介
单例模式是一种常用的软件设计模式,其属于创建型模式,其含义即是一个类只有一个实例,并为整个系统提供一个全局访问点 (向整个系统提供这个实)。
结构:
单例模式三要素:
私有的构造方法;
私有静态实例引用;
返回静态实例的静态公有方法。
单例模式的优点
在内存中只有一个对象,节省内存空间;
避免频繁的创建销毁对象,可以提高性能;
避免对共享资源的多重占用,简化访问;
为整个系统提供一个全局访问点。
单例模式的注意事项
在使用单例模式时,我们必须使用单例类提供的公有工厂方法得到单例对象,而不应该使用反射来创建,使用反射将会破坏单例模式 ,将会实例化一个新对象。
单线程实现方式
在单线程环境下,单例模式根据实例化对象时机的不同分为,
饿汉式单例(立即加载),饿汉式单例在单例类被加载时候,就实例化一个对象并将引用所指向的这个实例;
懒汉式单例(延迟加载),只有在需要使用的时候才会实例化一个对象将引用所指向的这个实例。
从速度和反应时间角度来讲,饿汉式(又称立即加载)要好一些;从资源利用效率上说,懒汉式(又称延迟加载)要好一些。
饿汉式单例
// 饿汉式单例
public class HungrySingleton{
// 私有静态实例引用,创建私有静态实例,并将引用所指向的实例
private static HungrySingleton singleton = new HungrySingleton();
// 私有的构造方法
private HungrySingleton(){}
//返回静态实例的静态公有方法,静态工厂方法
public static HungrySingleton getSingleton(){
return singleton;
}
}
饿汉式单例,在类被加载时,就会实例化一个对象并将引用所指向的这个实例;更重要的是,由于这个类在整个生命周期中只会被加载一次,只会被创建一次,因此恶汉式单例是线程安全的。
那饿汉式单例为什么是天生就线程安全呢?
因为类加载的方式是按需加载,且只加载一次。由于一个类在整个生命周期中只会被加载一次,在线程访问单例对象之前就已经创建好了,且仅此一个实例。即线程每次都只能也必定只可以拿到这个唯一的对象。
懒汉式单例
// 懒汉式单例
public class LazySingleton {
// 私有静态实例引用
private static LazySingleton singleton;
// 私有的构造方法
private LazySingleton(){}
// 返回静态实例的静态公有方法,静态工厂方法
public static LazySingleton getSingleton(){
//当需要创建类的时候创建单例类,并将引用所指向的实例
if (singleton == null) {
singleton = new LazySingleton();
}
return singleton;
}
}
懒汉式单例是延迟加载,只有在需要使用的时候才会实例化一个对象,并将引用所指向的这个对象。
由于是需要时创建,在多线程环境是不安全的,可能会并发创建实例,出现多实例的情况,单例模式的初衷是相背离的。那我们需要怎么避免呢?可以看接下来的多线程中单例模式的实现形式。
那为什么传统的懒汉式单例为什么是非线程安全的?
非线程安全主要原因是,会有多个线程同时进入创建实例(if (singleton == null) {}代码块)的情况发生。当这种这种情形发生后,该单例类就会创建出多个实例,违背单例模式的初衷。因此,传统的懒汉式单例是非线程安全的。
多线程实现方式
在单线程环境下,无论是饿汉式单例还是懒汉式单例,它们都能够正常工作。但是,在多线程环境下就有可能发生变异:
饿汉式单例天生就是线程安全的,可以直接用于多线程而不会出现问题
懒汉式单例本身是非线程安全的,因此就会出现多个实例的情况,与单例模式的初衷是相背离的。
那我们应该怎么在懒汉的基础上改造呢?
synchronized方法
synchronized块
使用内部类实现延迟加载
synchronized方法
// 线程安全的懒汉式单例
public class SynchronizedSingleton {
private static SynchronizedSingleton synchronizedSingleton;
private SynchronizedSingleton(){}
// 使用 synchronized 修饰,临界资源的同步互斥访问
public static synchronized SynchronizedSingleton getSingleton(){
if (synchronizedSingleton == null) {
synchronizedSingleton = new SynchronizedSingleton();
}
return synchronizedSingleton;
}
}
使用 synchronized 修饰 getSingleton()方法,将getSingleton()方法进行加锁,实现对临界资源的同步互斥访问,以此来保证单例。
虽然可现实线程安全,但由于同步的作用域偏大、锁的粒度有点粗,会导致运行效率会很低。
synchronized块
// 线程安全的懒汉式单例
public class BlockSingleton {
private static BlockSingleton singleton;
private BlockSingleton(){}
public static BlockSingleton getSingleton2(){
synchronized(BlockSingleton.class){ // 使用 synchronized 块,临界资源的同步互斥访问
if (singleton == null) {
singleton = new BlockSingleton();
}
}
return singleton;
}
}
其实synchronized块跟synchronized方法类似,效率都偏低。
使用内部类实现延迟加载
// 线程安全的懒汉式单例
public class InsideSingleton {
// 私有内部类,按需加载,用时加载,也就是延迟加载
private static class Holder {
private static InsideSingleton insideSingleton = new InsideSingleton();
}
private InsideSingleton() {
}
public static InsideSingleton getSingleton() {
return Holder.insideSingleton;
}
}
如上述代码所示,我们可以使用内部类实现线程安全的懒汉式单例,这种方式也是一种效率比较高的做法。其跟饿汉式单例原理是相同的, 但可能还存在反射攻击或者反序列化攻击 。
双重检查(Double-Check idiom)现实
双重检查(Double-Check idiom)-volatile
使用双重检测同步延迟加载去创建单例,不但保证了单例,而且提高了程序运行效率。
// 线程安全的懒汉式单例
public class DoubleCheckSingleton {
//使用volatile关键字防止重排序,因为 new Instance()是一个非原子操作,可能创建一个不完整的实例
private static volatile DoubleCheckSingleton singleton;
private DoubleCheckSingleton() {
}
public static DoubleCheckSingleton getSingleton() {
// Double-Check idiom
if (singleton == null) {
synchronized (DoubleCheckSingleton.class) {
// 只需在第一次创建实例时才同步
if (singleton == null) {
singleton = new DoubleCheckSingleton();
}
}
}
return singleton;
}
}
为了在保证单例的前提下提高运行效率,我们需要对singleton实例进行第二次检查,为的式避开过多的同步(因为同步只需在第一次创建实例时才同步,一旦创建成功,以后获取实例时就不需要同步获取锁了)。
但需要注意的必须使用volatile关键字修饰单例引用,为什么呢?
如果没有使用volatile关键字是可能会导致指令重排序情况出现,在Singleton 构造函数体执行之前,变量 singleton可能提前成为非 null 的,即赋值语句在对象实例化之前调用,此时别的线程将得到的是一个不完整(未初始化)的对象,会导致系统崩溃。
此可能为程序执行步骤:
线程 1 进入 getSingleton() 方法,由于 singleton 为 null,线程 1 进入 synchronized 块 ;
同样由于 singleton为 null,线程 1 直接前进到 singleton = new DoubleCheckSingleton()处,在new对象的时候出现重排序,导致在构造函数执行之前,使实例成为非 null,并且该实例并未初始化的(原因在NOTE);
此时,线程 2 检查实例是否为 null。由于实例不为 null,线程 2 得到一个不完整(未初始化)的 Singleton 对象;
线程 1 通过运行 Singleton对象的构造函数来完成对该对象的初始化。
这种安全隐患正是由于指令重排序的问题所导致的。而volatile 关键字正好可以完美解决了这个问题。使用volatile关键字修饰单例引用就可以避免上述灾难。
NOTE
new 操作会进行三步走,预想中的执行步骤:
memory = allocate(); //1:分配对象的内存空间
ctorInstance(memory); //2:初始化对象
singleton = memory; //3:使singleton3指向刚分配的内存地址但实际上,这个过程可能发生无序写入(指令重排序),可能会导致所下执行步骤:
memory = allocate(); //1:分配对象的内存空间
singleton3 = memory; //3:使singleton3指向刚分配的内存地址
ctorInstance(memory); //2:初始化对象
双重检查(Double-Check idiom)-ThreadLocal
借助于 ThreadLocal,我们可以实现双重检查模式的变体。我们将临界资源线程局部化,具体到本例就是将双重检测的第一层检测条件 if (instance == null) 转换为 线程局部范围内的操作 。
// 线程安全的懒汉式单例
public class ThreadLocalSingleton
// ThreadLocal 线程局部变量
private static ThreadLocal<ThreadLocalSingleton> threadLocal = new ThreadLocal<ThreadLocalSingleton>();
private static ThreadLocalSingleton singleton = null;
private ThreadLocalSingleton(){}
public static ThreadLocalSingleton getSingleton(){
if (threadLocal.get() == null) { // 第一次检查:该线程是否第一次访问
createSingleton();
}
return singleton;
}
public static void createSingleton(){
synchronized (ThreadLocalSingleton.class) {
if (singleton == null) { // 第二次检查:该单例是否被创建
singleton = new ThreadLocalSingleton(); // 只执行一次
}
}
threadLocal.set(singleton); // 将单例放入当前线程的局部变量中
}
}
借助于 ThreadLocal,我们也可以实现线程安全的懒汉式单例。但与直接双重检查模式使用,使用ThreadLocal的实现在效率上还不如双重检查锁定。
枚举实现方式
它不仅能避免多线程同步问题,而且还能防止反序列化重新创建新的对象,
直接通过Singleton.INSTANCE.whateverMethod()的方式调用即可。方便、简洁又安全。
public enum EnumSingleton {
instance;
public void whateverMethod(){
//dosomething
}
}
测试单例线程安全性
使用多个线程,并使用hashCode值计算每个实例的值,值相同为同一实例,否则为不同实例。
public class Test {
public static void main(String[] args) {
Thread[] threads = new Thread[10];
for (int i = 0; i < threads.length; i++) {
threads[i] = new TestThread();
}
for (int i = 0; i < threads.length; i++) {
threads[i].start();
}
}
}
class TestThread extends Thread {
public void run() {
// 对于不同单例模式的实现,只需更改相应的单例类名及其公有静态工厂方法名即可
int hash = Singleton5.getSingleton5().hashCode();
System.out.println(hash);
}
}
小结
单例模式是 Java 中最简单,也是最基础,最常用的设计模式之一。在运行期间,保证某个类只创建一个实例,保证一个类仅有一个实例,并提供一个访问它的全局访问点 ,介绍单例模式的各种写法:
饿汉式单例(线程安全)
懒汉式单例
传统懒汉式单例(线程安全);
使用synchronized方法实(线程安全);
使用synchronized块实现懒汉式单例(线程安全);
使用静态内部类实现懒汉式单例(线程安全)。
使用双重检查模式
使用volatile关键字(线程安全);
使用ThreadLocal实现懒汉式单例(线程安全)。
枚举式单例
参考文档:https://blog.csdn.net/czqqqqq/article/details/80451880
各位看官还可以吗?喜欢的话,动动手指点个
以上是关于盘扣式脚手架该怎样进行搭建和拆除?有啥技术要求呢?的主要内容,如果未能解决你的问题,请参考以下文章