单例设计模式

单例模式

 

保证一个类仅有一个实例,并提供一个访问它的全局访问点

public class SingletonClass{

    private static SingletonClass instance=null;

    public static SingletonClass getInstance(){

        if(instance==null){

            synchronized(SingletonClass.class){

                if(instance==null){

                    instance=new SingletonClass();

                }

            }

        }

        return instance;

    }

}

 

实现一个正确的单例模式

 

在熟悉的单例模式中你或许会遇到下面的方式来实现一个单例:

 

// version 1

class Singleton {

    private static Singleton _INSTANCE

 

 

    static Singleton getInstance() {

        if (_INSTANCE == null) {

            _INSTANCE = new Singleton()

        }

        return _INSTANCE;

    }

 

}

 

但是这个在多线程环境下会有问题:

Problem 1: 这个会创建多个Singleton对象.

 

那么我可以加上下面的同步就可以了:

 

// version 2

class Singleton {

    private static Singleton _INSTANCE

 

 

    static synchronized Singleton getInstance() {

        if (_INSTANCE == null) {

            _INSTANCE = new Singleton()

        }

        return _INSTANCE;

    }

 

}

 

这是一个完全正确的版本, 除了性能比较差.

 

那么我们可以直接不使用lazy init, 就可以不需要同步了:

 

// version 3

class Singleton {

    private static final Singleton _INSTANCE = new Singleton()

    static Singleton getInstance() {

        return _INSTANCE;

    }

}

 

这里final不是必须的.

static为我们提供了保证(正确的被创建, 创建的对象是完整的) 可以参考:JSR 133 (Java Memory Model) FAQ

 

恩 这很不错, 除了 也许我根本不需要它, 但是有可能我们需要用到的时候才创建.

 

所以, 便引出我们今天的双重检查版本:

 

// version 4

class Singleton {

    private static Singleton _INSTANCE

    static Singleton getInstance() {

        if (_INSTANCE == null) {

            synchronized (Singleton.class) {

                if (_INSTANCE) {

                    _INSTANCE = new Singleton()

                }

            }

        }

        return _INSTANCE;

    }

}

 

这个代码是无法工作的. 因为这个可能让其他线程看到没有完全构件好的对象:

 

// 原始代码

_INSTANCE = new Singleton()

// 实际上的步骤:

1.allocateMemory -> object 

2.Singleton._INSTANCE = object

3.init object attributes

 

实际上我们对2,3 的步骤是无法保证,

也就是如果2先执行 (指令重排), 那么其他线程可能看到构建了一半的对象.

 

所以常见的可以在多线程下正确工作的单例模式:

 

1. static init

2. object holder

3. synchronized 在class上同步

 

//object holder 

private static class LazySomethingHolder {

  public static Something something = new Something();

}

public static Something getInstance() {

  return LazySomethingHolder.something;

}

FFmpeg是一款功能强大的开源多媒体处理工具,广泛应用于视频和音频的编码、解码、转换以及流媒体处理。然而,由于历史原因和标准限制,原生的FFmpeg并不支持将H.265(高效视频编码)格式的视频流封装到FLV(Flash Video)容器中。FLV是一种常见的网络流媒体传输格式,但其最初设计时并未考虑现代高效的H.265编码标准。因此,当尝试将H.265编码的视频与FLV容器结合时,会出现“Video codec hevc not compatible with flv”的错误提示,表明FFmpeg无法识别这种组合。 为了解决这一问题,开发者通常需要对FFmpeg的源代码进行修改和扩展。一个名为“用于解决ffmpeg不支持flv+h265需要修改的文件.zip”的压缩包中包含了一些源代码文件,这些文件旨在扩展FFmpeg的功能,使其能够处理FLV容器中的H.265编码内容。压缩包中的三个关键文件分别是“flvdec.c”“flvenc.c”和“flv.h”,它们分别对应FLV的解码器、编码器和头文件。 flvdec.c:这是FFmpeg的FLV解码器源代码,经过修改后可能支持读取和解析包含H.265数据的FLV流。解码器的作用是从FLV容器中提取视频数据,并将其转换为可处理的原始像素格式。 flvenc.c:这个文件包含FLV编码器的源代码,经过调整后可能允许将H.265编码的视频流封装到FLV容器中。编码器负责将原始视频数据编码为H.265格式,并将其打包到FLV文件中。 flv.h:这是一个头文件,定义了FLV格式相关的常量、结构体和函数原型。修改该文件可能涉及添加或更新与H.265支持相关的定义和接口。 要应用这些修改,开发者需要重新编译FFmpeg源代码,并将修改后的版本替换原有的FFmpeg安装。这样,用户就可以使用定制版的FFmpeg来处理FLV+H.265的
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值