023＊：定时器和锁原理（ Dispatch_source_t NSTimer CADisplayLink） @synchronized（SyncList SyncData threadCount lockCount ）（NSLock当前线程一把锁）（NSRecursiveLock当前线程递归锁相当多把锁）（NSCondition线程+锁）（NSConditionLock线程、条件和锁）

自旋锁和互斥锁：区别

1：而Spin lock（自旋锁）则不然，它属于busy-waiting类型的锁，如果线程A是使用pthread_spin_lock操作去请求锁，那么线程A就会一直在Core0上进行忙等待并不停的进行锁请求，直到得到这个锁为止。

自旋锁（Spin lock）

自旋锁与互斥锁有点类似，只是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，“自旋锁”的作用是为了解决某项资源的互斥使用。因为自旋锁不会引起调用者睡眠，所以自旋锁的效率远高于互斥锁。

自旋锁的不足之处：

1：自旋锁一直占用着CPU，他在未获得锁的情况下，一直运行（自旋），所以占用着CPU，如果不能在很短的时间内获得锁，这无疑会使CPU效率降低。

2：在用自旋锁时有可能造成死锁，当递归调用时有可能造成死锁。

死锁产生的4个必要条件

1、互斥：某种资源一次只允许一个进程访问，即该资源一旦分配给某个进程，其他进程就不能再访问，直到该进程访问结束。

2、占有且等待：一个进程本身占有资源（一种或多种），同时还有资源未得到满足，正在等待其他进程释放该资源。

3、不可抢占：别人已经占有了某项资源，你不能因为自己也需要该资源，就去把别人的资源抢过来。

4、循环等待：存在一个进程链，使得每个进程都占有下一个进程所需的至少一种资源。

当以上四个条件均满足，必然会造成死锁，发生死锁的进程无法进行下去，它们所持有的资源也无法释放。这样会导致CPU的吞吐量下降。所以死锁情况是会浪费系统资源和影响计算机的使用性能的。那么，解决死锁问题就是相当有必要的了。

1：定时器

Dispatch_source_t的计时器与NSTimer、CADisplayLink比较？

1. NSTimer

存在延迟，与RunLoop和RunLoop Mode有关
（如果Runloop正在执行一个连续性运算，timer会被延时触发）
需要手动加入RunLoop，且Model需要设置为forMode:NSCommonRunLoopMode
（NSDefaultRunLoopMode模式，触摸事件会让计时器暂停）

NSTimer *timer = [NSTimer timerWithTimeInterval:5 
                                         target:self  
                                       selector:@selector(timerAction) 
                                      userInfo:nil 
                                       repeats:YES];
[[NSRunLoop mainRunLoop] addTimer:timer forMode:NSCommonRunLoopMode];

2. CADisplayLink

屏幕刷新时调用CADisplayLink，以和屏幕刷新频率同步的频率将特定内容画在屏幕上的定时器类。
CADisplayLink以特定模式注册到runloop后，每当屏幕显示内容刷新结束的时候，runloop就会向CADisplayLink指定的target发送一次指定的selector消息， CADisplayLink类对应的selector就会被调用一次。所以通常情况下，按照iOS设备屏幕的刷新率60次/秒
CADisplayLink在正常情况下会在每次刷新结束都被调用，精确度相当高。
但如果调用的方法比较耗时，超过了屏幕刷新周期，就会导致跳过若干次回调调用机会。
如果CPU过于繁忙，无法保证屏幕60次/秒的刷新率，就会导致跳过若干次调用回调方法的机会，跳过次数取决CPU的忙碌程度。

3. dispatch_source_t 计时器

时间准确，可以使用子线程，解决跑在主线程上卡UI的问题
不依赖runloop，基于系统内核进行处理，准确性非常高

区别

NSTimer会受到主线程的任务的影响，CADisplayLink会受到CPU负载的影响，产生延迟。
dispatch_source_t可以使用子线程，而且可以使用leeway参数指定可以接受的误差来降低资源消耗

2：各种类型`锁`的`耗时比较`：

可以看出，图中锁的性能从高到底依次是：

OSSpinLock(自旋锁) -> dispatch_semaphone（信号量） -> pthread_mutex（互斥锁） -> NSLock（互斥锁） -> NSCondition（条件锁） -> pthread_mutex（recursive 互斥递归锁） -> NSRecursiveLock（递归锁） -> NSConditionLock（条件锁） -> synchronized（互斥锁）

1：互斥锁

互斥锁：互斥锁是一种用于多线程编程中，防止两条线程同时对同一公共资源（例如全局变量）进行读写的机制，该目的是通过将代码切成一个个临界区而达成

@synchronized（递归互斥锁）

NSLock

pthread_mutex

2：条件锁:条件锁就是条件变量，当进程的某些资源要求不满足时就进入休眠，即锁住了，当资源被分配到了，条件锁打开了，进程继续运行

NSCondition

NSConditionLock

3：递归锁:(递归互斥锁)递归锁就是同一个线程可以加锁N次而不会引发死锁。递归锁是特殊的互斥锁，即是带有递归性质的互斥锁

pthread_mutex(recursive)

NSRecursiveLock

4：信号量（互斥锁）：信号量是一种更高级的同步机制，互斥锁可以说是semaphore在仅取值0/1时的特例，信号量可以有更多的取值空间，用来实现更加复杂的同步，而不单单是线程间互斥

dispatch_semaphore

一、@synchronized

开启汇编调试，发现@synchronized在执行过程中，会走底层的objc_sync_enter 和 objc_sync_exit方法

1：objc_sync_enter 分析

int objc_sync_enter(id obj)
{
    int result = OBJC_SYNC_SUCCESS;

    if (obj) {//传入不为nil
        SyncData* data = id2data(obj, ACQUIRE);//重点
        ASSERT(data);
        data->mutex.lock();//加锁
    } else {//传入nil
        // @synchronized(nil) does nothing
        if (DebugNilSync) {
            _objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
        }
        objc_sync_nil();
    }

    return result;
}

进入objc_sync_enter源码实现

如果obj存在，则通过id2data方法获取相应的SyncData，对threadCount、lockCount进行递增操作
如果obj不存在，则调用objc_sync_nil，通过符号断点得知，这个方法里面什么都没做，直接return了

2：objc_sync_exit 分析

进入objc_sync_exit源码实现

// End synchronizing on 'obj'. 结束对“ obj”的同步
// Returns OBJC_SYNC_SUCCESS or OBJC_SYNC_NOT_OWNING_THREAD_ERROR
int objc_sync_exit(id obj)
{
    int result = OBJC_SYNC_SUCCESS;
    
    if (obj) {//obj不为nil
        SyncData* data = id2data(obj, RELEASE); 
        if (!data) {
            result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
        } else {
            bool okay = data->mutex.tryUnlock();//解锁
            if (!okay) {
                result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
            }
        }
    } else {//obj为nil时，什么也不做
        // @synchronized(nil) does nothing
    }
    return result;
}

如果obj存在，则调用id2data方法获取对应的SyncData，对threadCount、lockCount进行递减操作
如果obj为nil，什么也不做

3：SyncData

typedef struct alignas(CacheLineSize) SyncData {
    struct SyncData* nextData;//类似链表结构
    DisguisedPtr<objc_object> object;
    int32_t threadCount;  // number of THREADS using this block
    recursive_mutex_t mutex;//递归锁
} SyncData;

进入SyncData的定义，是一个结构体，主要用来表示一个线程data，类似于链表结构，有next指向，且封装了recursive_mutex_t属性，可以确认@synchronized确实是一个递归互斥锁

进入SyncCache的定义，也是一个结构体，用于存储线程，其中list[0]表示当前线程的链表data，主要用于存储SyncData和lockCount

typedef struct {
    SyncData *data;
    unsigned int lockCount;  // number of times THIS THREAD locked this block
} SyncCacheItem;

typedef struct SyncCache {
    unsigned int allocated;
    unsigned int used;
    SyncCacheItem list[0];
} SyncCache;

4：id2data 分析

static SyncData* id2data(id object, enum usage why)
{
    spinlock_t *lockp = &LOCK_FOR_OBJ(object);
    SyncData **listp = &LIST_FOR_OBJ(object);
    SyncData* result = NULL;

#if SUPPORT_DIRECT_THREAD_KEYS //tls（Thread Local Storage，本地局部的线程缓存）
    // Check per-thread single-entry fast cache for matching object
    bool fastCacheOccupied = NO;
    //通过KVC方式对线程进行获取 线程绑定的data
    SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
    //如果线程缓存中有data，执行if流程
    if (data) {
        fastCacheOccupied = YES;
        //如果在线程空间找到了data
        if (data->object == object) {
            // Found a match in fast cache.
            uintptr_t lockCount;

            result = data;
            //通过KVC获取lockCount，lockCount用来记录 被锁了几次，即 该锁可嵌套
            lockCount = (uintptr_t)tls_get_direct(SYNC_COUNT_DIRECT_KEY);
            if (result->threadCount <= 0  ||  lockCount <= 0) {
                _objc_fatal("id2data fastcache is buggy");
            }

            switch(why) {
            case ACQUIRE: {
                //objc_sync_enter走这里，传入的是ACQUIRE -- 获取
                lockCount++;//通过lockCount判断被锁了几次，即表示 可重入（递归锁如果可重入，会死锁）
                tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);//设置
                break;
            }
            case RELEASE:
                //objc_sync_exit走这里，传入的why是RELEASE -- 释放
                lockCount--;
                tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
                if (lockCount == 0) {
                    // remove from fast cache
                    tls_set_direct(SYNC_DATA_DIRECT_KEY, NULL);
                    // atomic because may collide with concurrent ACQUIRE
                    OSAtomicDecrement32Barrier(&result->threadCount);
                }
                break;
            case CHECK:
                // do nothing
                break;
            }

            return result;
        }
    }
#endif

    // Check per-thread cache of already-owned locks for matching object
    SyncCache *cache = fetch_cache(NO);//判断缓存中是否有该线程
    //如果cache中有，方式与线程缓存一致
    if (cache) {
        unsigned int i;
        for (i = 0; i < cache->used; i++) {//遍历总表
            SyncCacheItem *item = &cache->list[i];
            if (item->data->object != object) continue;

            // Found a match.
            result = item->data;
            if (result->threadCount <= 0  ||  item->lockCount <= 0) {
                _objc_fatal("id2data cache is buggy");
            }
                
            switch(why) {
            case ACQUIRE://加锁
                item->lockCount++;
                break;
            case RELEASE://解锁
                item->lockCount--;
                if (item->lockCount == 0) {
                    // remove from per-thread cache 从cache中清除使用标记
                    cache->list[i] = cache->list[--cache->used];
                    // atomic because may collide with concurrent ACQUIRE
                    OSAtomicDecrement32Barrier(&result->threadCount);
                }
                break;
            case CHECK:
                // do nothing
                break;
            }

            return result;
        }
    }

    // Thread cache didn't find anything.
    // Walk in-use list looking for matching object
    // Spinlock prevents multiple threads from creating multiple 
    // locks for the same new object.
    // We could keep the nodes in some hash table if we find that there are
    // more than 20 or so distinct locks active, but we don't do that now.
    //第一次进来，所有缓存都找不到
    lockp->lock();

    {
        SyncData* p;
        SyncData* firstUnused = NULL;
        for (p = *listp; p != NULL; p = p->nextData) {//cache中已经找到
            if ( p->object == object ) {//如果不等于空，且与object相似
                result = p;//赋值
                // atomic because may collide with concurrent RELEASE
                OSAtomicIncrement32Barrier(&result->threadCount);//对threadCount进行++
                goto done;
            }
            if ( (firstUnused == NULL) && (p->threadCount == 0) )
                firstUnused = p;
        }
    
        // no SyncData currently associated with object 没有与当前对象关联的SyncData
        if ( (why == RELEASE) || (why == CHECK) )
            goto done;
    
        // an unused one was found, use it 第一次进来，没有找到
        if ( firstUnused != NULL ) {
            result = firstUnused;
            result->object = (objc_object *)object;
            result->threadCount = 1;
            goto done;
        }
    }

    // Allocate a new SyncData and add to list.
    // XXX allocating memory with a global lock held is bad practice,
    // might be worth releasing the lock, allocating, and searching again.
    // But since we never free these guys we won't be stuck in allocation very often.
    posix_memalign((void **)&result, alignof(SyncData), sizeof(SyncData));//创建赋值
    result->object = (objc_object *)object;
    result->threadCount = 1;
    new (&result->mutex) recursive_mutex_t(fork_unsafe_lock);
    result->nextData = *listp;
    *listp = result;
    
 done:
    lockp->unlock();
    if (result) {
        // Only new ACQUIRE should get here.
        // All RELEASE and CHECK and recursive ACQUIRE are 
        // handled by the per-thread caches above.
        if (why == RELEASE) {
            // Probably some thread is incorrectly exiting 
            // while the object is held by another thread.
            return nil;
        }
        if (why != ACQUIRE) _objc_fatal("id2data is buggy");
        if (result->object != object) _objc_fatal("id2data is buggy");

#if SUPPORT_DIRECT_THREAD_KEYS
        if (!fastCacheOccupied) { //判断是否支持栈存缓存，支持则通过KVC形式赋值 存入tls
            // Save in fast thread cache
            tls_set_direct(SYNC_DATA_DIRECT_KEY, result);
            tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)1);//lockCount = 1
        } else 
#endif
        {
            // Save in thread cache 缓存中存一份
            if (!cache) cache = fetch_cache(YES);//第一次存储时，对线程进行了绑定
            cache->list[cache->used].data = result;
            cache->list[cache->used].lockCount = 1;
            cache->used++;
        }
    }

    return result;
}

第一步】首先在tls即线程缓存中查找。
- 在tls_get_direct方法中以线程为key，通过KVC的方式获取与之绑定的SyncData，即线程data。其中的tls（），表示本地局部的线程缓存，
- 判断获取的data是否存在，以及判断data中是否能找到对应的object
- 如果都找到了，在tls_get_direct方法中以KVC的方式获取lockCount，用来记录对象被锁了几次（即锁的嵌套次数）
- 如果data中的threadCount小于等于0，或者 lockCount小于等于0时，则直接崩溃
- 通过传入的why，判断是操作类型
  - 如果是ACQUIRE，表示加锁，则进行lockCount++，并保存到tls缓存
  - 如果是RELEASE，表示释放，则进行lockCount--，并保存到tls缓存。如果lockCount等于 0，从tls中移除线程data
  - 如果是CHECK，则什么也不做

【第二步】如果tls中没有，则在cache缓存中查找
- 通过fetch_cache方法查找cache缓存中是否有线程
- 如果有，则遍历cache总表，读取出线程对应的SyncCacheItem
- 从SyncCacheItem中取出data，然后后续步骤与tls的匹配是一致的
【第三步】如果cache中也没有，即第一次进来，则创建SyncData，并存储到相应缓存中
- 如果在cache中找到线程，且与object相等，则进行赋值、以及threadCount++
- 如果在cache中没有找到，则threadCount等于1

所以在id2data方法中，主要分为三种情况

【第一次进来，没有锁】：
- threadCount = 1
- lockCount = 1
- 存储到tls
【不是第一次进来，且是同一个线程】
- tls中有数据，则lockCount++
- 存储到tls
【不是第一次进来，且是不同线程】
- 全局线程空间进行查找线程
- threadCount++
- lockCount++
- 存储到cache

总结：

哈希表结构中通过SyncList结构来组装多线程的情况

SyncData通过链表的形式组装当前可重入的情况锁：即可嵌套

下层通过tls线程缓存、cache缓存来进行处理

底层主要有两个东西：lockCount、threadCount,解决了递归互斥锁，解决了嵌套可重入

2：NSLock、NSRecursiveLock、@synchronized三者的区别

- (void)demo{
    for (int i= 0; i<10; i++) {
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
           
            static void (^testMethod)(int);// 1. 声明
            
            testMethod = ^(int value){  // 2. 实现Block块
                if (value > 0) {
                  NSLog(@"current value = %d",value);
                  testMethod(value - 1); // 4. 嵌套调用block
                }
            };
            
            testMethod(10); // 3.调用block
        });
    }
}

1：NSLock锁，只锁了当前线程，当我们使用异步多线程操作时，可能出现线程间相互等待，死锁的情况

所以如果使用NSLock锁，必须在声明前加锁和调用后解锁，才能解决数据的读写安全问题。

但由于它具备递归特性，我们在block内部的递归前加锁，当前线程也打印正常，但是其他线程堵塞。

2：使用`NSRecursiveLock`

但由于它具备递归特性，我们在block内部的递归前加锁，当前线程也打印正常，但是其他线程堵塞。

当我们去掉for循环，仅保持一个异步线程，在block内部的递归前后分别加锁和解锁，

3：@synchronized

@synchronized最简单，直接将block内部代码包裹起来，就可以实现数据读写安全了

@synchronized能对记录被锁对象的所有线程，每个线程内部都是递归持有任务的。所以在异步多线程中，它既不用担心递归造成的锁释放问题，也不需要关心线程间的通信问题。

NSLock、NSRecursiveLock、@synchronized三者的区别

NSLock:

需要手动创建和释放，需要在准确的时机进行相应操作。

仅锁住当前线程的当前任务，无法自动实现线程间的通讯和递归问题。
（上述NSLock代码实际上没解决递归问题，只是野蛮的在代码最外层上了一把大锁，无视递归内部层级）

NSRecursiveLock:

需要手动创建和释放，需要在准确的时机进行相应操作。

仅锁住当前线程的所有任务，无法自动实现线程间的通讯，但可以解决递归问题。
（与NSLock不同，NSRecursiveLock是在递归时，每层加锁和解锁。对锁的控制更为精确）

@synchronized:

只需将需要锁的代码都放在作用域内，确定被锁对象(被锁对象决定了锁的生命周期)，@synchronized就可以做到自动创建和释放。

锁住被锁对象的所有线程的所有任务，可自动实现线程间的通讯，可以解决递归问题。
(内部逻辑为： 被锁对象可持有多个线程，每个线程可递归持有多个任务)

所以我们日常使用时，尽管@synchronized耗时较大，但是它使用非常简单，根本不需要处理各种异常情况，也不需要手动释放。便捷性和安全性都非常好。

3：NSCondition 多线程中用

NSCondition的对象实际上是作为一个锁和一个线程检查器:

锁：当检查条件成立时，保护数据源
线程检查器：根据条件判断是否继续运行线程（线程是否阻塞

方法：

[condition lock]：加锁
（一般用于多线程同时访问、修改同一个数据源时，保证同一时间内数据源只能被访问、修改一次，其他线程的命令需要在lock外等待，只有unlock后，才可访问）

[condition unlock]：解锁（与lock配对使用）

[condition wait]：让当前线程处于等待状态

[condition signal]：CPU发信号告诉所有线程不用再等待，可以继续执行。

测试案例：
有2个生产者和2个消费者，各自生产和消费各50次。当消费者购买时，没货就排队等待，有货就卖货,一次只能一个人买，每当生产者生产出一个货物时，都会广播告诉所有等待的消费者，进行继续购买。
这样保障了货品的数据安全（有货才能卖，一次卖一个，没货就等待）

@interface ViewController ()
@property (nonatomic, assign) NSUInteger ticketCount;
@property (nonatomic, strong) NSCondition *testCondition;
@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    self.ticketCount = 0;
    [self demo];
}

- (void)demo{
    
    _testCondition = [[NSCondition alloc] init];
    
    //创建生产-消费者
    for (int i = 0; i < 50; i++) {
        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
            [self producer]; // 生产者
        });
        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
            [self consumer]; // 消费者
        });
        
        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
            [self consumer]; // 消费者
        });
        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
            [self producer]; // 生产者
        });
    }
}

- (void)producer{
    [_testCondition lock]; // 操作的多线程影响
    self.ticketCount = self.ticketCount + 1;
    NSLog(@"生产一个 现有 count %zd",self.ticketCount);
    [_testCondition signal]; // 发送信号
    [_testCondition unlock];
}

- (void)consumer{
 
     [_testCondition lock];  // 操作的多线程影响
    if (self.ticketCount == 0) {
        NSLog(@"等待 count %zd",self.ticketCount);
        [_testCondition wait]; // 线程等待
    }
    //注意消费行为，要在等待条件判断之后
    self.ticketCount -= 1;
    NSLog(@"消费一个 还剩 count %zd ",self.ticketCount);
     [_testCondition unlock];
}
@end

打印结果：（生产消费数据是安全的）

但是NSCondition使用非常麻烦，需要在合适的地方手动加锁、等待、发送信号、释放
于是基于NSCondition，出现了NSConditionLock锁

4. NSConditionLock：

方法：

[xxx lock]：加锁
- 如果没有其他线程获得锁（不需要判断内部的condition），那他能执行后续代码，同时设置当前线程获得锁。
- 如果已经有其他线程获得锁（可能是条件锁，或者无条件锁），则等待，直到其他线程解锁
[xxx lockWhenCondition: A条件]：
- 在[xxx lock]的基础上，没有其他线程获得锁，且内部的condition条件满足A条件时，才会执行后续代码并让当前线程获得锁。否则依旧是等待
[xxx unlockWithCondition: A条件]：释放锁
- 把内部的condition设置为A条件，并broadcast广播告诉所有等待的线程。
return = [xxx lockWhenCondition: A条件 beforeDate: A时间]：
- 没有其他线程获得锁，且满足A条件，且在A时间之前，可以执行后续代码并让当前线程获得锁。
- 返回值为NO，表示没有改变锁的状态
condition是整数，内部通过整数比较条件

通过下面案例分析：

- (void)demo{

    NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:2];
    
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
         [conditionLock lockWhenCondition:1]; // conditoion = 1 内部 Condition 匹配
        NSLog(@"线程 1");
         [conditionLock unlockWithCondition:0]; // 解锁并把conditoion设置为0
    });
    
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^{
       
        [conditionLock lockWhenCondition:2]; // conditoion = 2 内部 Condition 匹配
        sleep(0.1);
        NSLog(@"线程 2");
        [conditionLock unlockWithCondition:1]; // 解锁并把conditoion设置为1
    });
    
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
       
       [conditionLock lock]; 
       NSLog(@"线程 3");
       [conditionLock unlock];
    });
}

分析：

有三个并行队列+异步函数，分别处理三个任务，三个任务的执行顺序无序。
（并行队列+异步线程是的执行顺序是不固定的，取决于任务资源大小和cpu的调度）
我们init时，将condition设置为2。
- 任务1：必须当前线程没被锁，且condition为1时，我才加锁并执行后面代码。
- 任务2：必须当前线程没被锁，且condition为2时，我才加锁并执行后面代码。
- 任务3：必须当前线程没被锁，我可以加锁并执行后面代码。

所以任务3的执行时期并不确定，只要当前线程没被锁，随时都可以。 任务1一定在任务2的后面：

因为condition初始值为2，只有任务2满足条件，任务2执行完后，将condition设置为1，并broadcast广播给所有等待的线程。
此时正在等待的任务1的线程收到广播，检查任务1，满足条件，任务1执行完后，将condition设置为0，并broadcast广播给所有等待的线程。

Swift Foundation源码中搜索NSConditionLock，可以看到循环检查线程、条件和上锁过程:

posted on 2020-12-03 11:26 风zk 阅读(153) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

风zk