当前位置： 首页 > news >正文

iOS——线程安全、线程同步与线程通信

news 来源：原创 2024/9/21 1:25:28

线程安全和线程同步

  • 线程安全：如果你的代码所在的进程中有多个线程在同时运行，而这些线程可能会同时运行这段代码。如果每次运行结果和单线程运行的结果是一样的，而且其他的变量的值也和预期的是一样的，就是线程安全的。

若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时执行写操作（更改变量），一般都需要考虑线程同步，否则的话就可能影响线程安全。

  • 线程同步：可理解为线程 A 和 线程 B 一块配合，A 执行到一定程度时要依靠线程 B 的某个结果，于是停下来，示意 B 运行；B 依言执行，再将结果给 A；A 再继续操作。

多线程的安全隐患

  • 资源共享
    1块资源可能会被多个线程共享，也就是多个线程可能会访问同一块资源
    比如多个线程访问同一个对象、同一个变量、同一个文件

  • 当多个线程访问同一块资源时，很容易引发数据错乱和数据安全问题

例子：
如以下的抢票代码：

@interface ViewController ()
@property (assign, nonatomic) int ticketsCount;
@end@implementation ViewController- (void) viewDidLoad {[super viewDidLoad];self.ticketsCount = 100;[self test];
}- (void) test {dispatch_queue_t queue = dispatch_get_global_queue(0, 0);dispatch_async(queue, ^{for (int i = 0; i < 100; i++) {[NSThread sleepForTimeInterval:0.1];[self cunTicket];}});dispatch_async(queue, ^{for (int i = 0; i < 100; i++) {[NSThread sleepForTimeInterval:0.1];[self quTicket];}});
}- (void) cunTicket {int oldTicket = self.ticketsCount;self.ticketsCount = oldTicket + 1;NSLog(@"加1票：%d", self.ticketsCount);
}- (void) quTicket {int oldTicket = self.ticketsCount;self.ticketsCount = oldTicket - 1;NSLog(@"减1票：%d", self.ticketsCount);
}@end

执行结果：
请添加图片描述

数据发生了错误

多线程安全隐患分析

请添加图片描述

  • 解决方案：使用线程同步技术（同步，就是协同步调，按预定的先后次序进行）
  • 常见的线程同步技术是：加锁

请添加图片描述

线程A访问Integer的时候先加锁，访问完成后解锁
在线程B访问加锁，完成后解锁。

线程同步

iOS中的线程同步方案

  • OSSpinLock
  • os_unfair_lock
  • pthread_mutex
  • dispatch_semaphore
  • dispatch_queue(DISPATCH_QUEUE_SERIAL) //串行队列
  • NSLock
  • NSRecursiveLock
  • NSCondition
  • NSConditionLock
  • @synchronized

OSSpinLock（自旋锁）

自旋锁与互斥锁有点类似，只是自旋锁不会引起调用者睡眠，所以自旋锁的效率远高于互斥锁。如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是 否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名。

虽然它的效率比互斥锁高，但是它也有些不足之处：

  • 自旋锁的等待锁的线程会处于忙等（busy-wait）状态，一直占用着CPU资源。如果等待锁的线程优先级较高，它会一直占用着CPU资源，优先级低的线程就无法释放锁。
  • 使用自旋锁不容易解决优先级反转问题。
  • 在用自旋锁时有可能造成死锁，当递归调用时有可能造成死锁，调用有些其他函数也可能造成死锁，如 copy_to_user()、copy_from_user()、kmalloc()等。

自旋锁只有在内核可抢占式或SMP的情况下才真正需要，在单CPU且不可抢占式的内核下，自旋锁的操作为空操作。自旋锁适用于锁使用者保持锁时间比较短的情况下。

优先级反转问题

例子：
请添加图片描述

线程A在一个比较低的优先级上工作, 假设是10吧。然后在时间点T1的时候，线程A锁定了一把互斥锁，并开始操作互斥数据。
这时有个高优线级线程C（比如优先级20）在时间点T2被唤醒，它也也需要操作互斥数据。当它加锁互斥锁时，因为互斥锁在T1被线程A锁掉了，所以线程C放弃CPU进入阻塞状态，而线程A得以占据CPU，继续执行。
事情到这一步还是正确的，虽然优先级10的A线程看上去抢了优先级20的C线程的时间，但因为程序逻辑，C确实需要退出CPU等完成互斥数据操作后，才能获得CPU。
但是，假设我们有个线程B在优先级15上，在T3时间点上醒了过来，因为他比当前执行的线程A优先级高，所以它会立即抢占CPU。而线程A被迫进入READY状态等待。
一直到时间点T4，线程B放弃CPU，这时优先级10的线程A是唯一READY线程，它再次占据CPU继续执行，最后在T5解锁了互斥锁。
在T5，线程A解锁的瞬间，线程C立即获取互斥锁，并在优先级20上等待CPU。因为它比线程A的优先级高，系统立刻调度线程C执行，而线程A再次进入READY状态。

上面这个时序里，线程B从T3到T4占据CPU运行的行为，就是事实上的优先级反转。一个优先级15的线程B，通过压制优线级10的线程A，而事实上导致高优先级线程C无法正确得到CPU。这段时间是不可控的，因为线程B可以长时间占据CPU（即使轮转时间片到时，线程A和B都处于可执行态，但是因为B的优先级高，它依然可以占据CPU），其结果就是高优先级线程C可能长时间无法得到 CPU。

优先级反转问题和自旋锁

优先级反转问题的出现跟自旋锁没有关系
不使用自旋锁时也可能出现优先级反转问题。只要是线程或任务有多个优先级，理论上就可能有反转问题。操作系统在优先级反转发生时通常都会有自动的解决方案，比如提高低优先级线程的优先级等

在使用iOS中的OSSpinLock自旋锁时，由于这种锁不会记录持有它的线程信息，所有当发生优先级反转时，系统找不到低优先级的线程，可能因此无法通过提高优先级解决优先级反转问题。再加上，高优先级线程使用自旋锁进行轮训等待锁时在一直占用CPU时间片，使得低优先级线程拿到时间片的概率降低

总结下来是

  • 优先级反转问题的出现跟自旋锁没有关系
  • 但一旦出现优先级反转问题，自旋锁会让优先级反转问题不容易解决，甚至造成更严重的线程等待问题

互斥锁

互斥锁和自旋锁的区别是，当线程获取锁操作失败的时候，线程会进入睡眠，即它是sleep-waiting，而自旋锁是会使线程进入忙等busy-waiting。如果线程是使用pthread_spin_lock操作去请求自旋锁，那么线程就会一直进行忙等待并不停的进行锁请求，直到得到这个锁为止。

互斥锁用于临界区持锁时间比较长的操作，比如下面这些情况都可以考虑

  1. 临界区有IO操作
  2. 临界区代码复杂或者循环量大
  3. 临界区竞争非常激烈
  4. 单核处理器

两种锁的加锁原理

自旋锁：线程一直是running(加锁——>解锁)，死循环检测锁的标志位，机制不复杂。
互斥锁：线程会从sleep（加锁）——>running（解锁），过程中有上下文的切换，cpu的抢占，信号的发送等开销。

对比 :互斥锁的起始原始开销要高于自旋锁，但是基本是一劳永逸，临界区持锁时间的大小并不会对互斥锁的开销造成影响，而自旋锁是死循环检测，加锁全程消耗cpu，起始开销虽然低于互斥锁，但是随着持锁时间，加锁的开销是线性增长。

两种锁的使用

自旋锁的使用

在使用自旋锁之前，需要导入头文件#import<libkern/OSAtomic.h>

//初始化
OSSpinLock lock = OS_SPINLOCK_INIT;
//加锁
OSSpinLockLock(&lock);
//解锁
OSSpinLockUnlock(&lock);

互斥锁的使用

OSSpinLock在iOS10.0以后就被弃用了，可以使用os_unfair_lock替代:
需要导入头文件#import <os/lock.h>:

//初始化
os_unfair_lock lock = OS_UNFAIR_LOCK_INIT;
//加锁
os_unfair_lock_lock(&lock);
//解锁
os_unfair_lock_unlock(&lock);

pthread_mutex：
mutex叫做”互斥”，等待锁的线程会处于休眠状态。需要导入头文件#import <pthread.h>

1、初始化锁的属性
//声明一个互斥锁属性变量
pthread_mutexattr_t attr;
//初始化该属性变量，使其包含默认值
pthread_mutexattr_init(&attr);
//将互斥锁属性设置为递归锁类型
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);/*
* Mutex type attributes
*/#define PTHREAD_MUTEX_NORMAL        0   // 普通锁
#define PTHREAD_MUTEX_ERRORCHECK    1   // 错误检查锁
#define PTHREAD_MUTEX_RECURSIVE     2   // 递归锁
#define PTHREAD_MUTEX_DEFAULT       PTHREAD_MUTEX_NORMAL // 默认锁类型2、初始化锁
pthread_mutex_init(mutex, &attr);3、初始化锁结束以后，销毁属性
pthread_mutexattr_destroy(&attr);4、加锁解锁
pthread_mutex_lock(&_mutex);
pthread_mutex_unlock(&_mutex);5、// 初始化条件
pthread_cond_t condition
pthread_cond_init(&_cond, NULL);6、// 等待条件
pthread_cond_wait(&_cond, &_mutex);7、//激活一个等待该条件的线程
pthread_cond_signal(&_cond);
//激活所有等待该条件的线程
pthread_cond_broadcast(&_cond);8、//销毁资源
pthread_mutex_destroy(&_mutex);
pthread_cond_destroy(&_cond);备注：我们可以不初始化属性，在传属性的时候直接传NULL，表示使用默认属性PTHREAD_MUTEX_NORMAL。pthread_mutex_init(mutex, NULL);

PTHREAD_MUTEX_RECURSIVE递归锁：允许同一个线程对同一把锁进行重复加锁。要看着重点同一个线程和同一把锁

NSLock:
NSLock是对mutex普通锁的封装。pthread_mutex_init(mutex, NULL);
NSLock 遵循 NSLocking 协议。Lock 方法是加锁，unlock 是解锁，tryLock 是尝试加锁，如果失败的话返回 NO，lockBeforeDate: 是在指定Date之前尝试加锁，如果在指定时间之前都不能加锁，则返回NO

其他实现同步的方法

NSRecursiveLock

NSRecursiveLock是对mutex递归锁的封装，API跟NSLock基本一致

NSCondition

NSCondition是对mutex和cond的封装，更加面向对象，我们使用起来也更加的方便简洁

NSConditionLock

NSConditionLock是对NSCondition的进一步封装，可以设置具体的条件值

@interface NSConditionLock : NSObject <NSLocking>// 初始化方法，根据给定的条件初始化锁
- (instancetype)initWithCondition:(NSInteger)condition;
// 只读属性，返回当前锁的条件
@property (readonly) NSInteger condition;
// 当条件满足时锁定
- (void)lockWhenCondition:(NSInteger)condition;
// 尝试锁定，如果锁已经被其他线程占用则返回 NO
- (BOOL)tryLock;
// 当条件满足时尝试锁定，如果锁已经被其他线程占用或条件不满足则返回 NO
- (BOOL)tryLockWhenCondition:(NSInteger)condition;
// 解锁并设置新的条件
- (void)unlockWithCondition:(NSInteger)condition;
// 在指定的时间之前尝试锁定，如果成功返回 YES，否则返回 NO
- (BOOL)lockBeforeDate:(NSDate *)limit;
// 在指定的时间之前当条件满足时尝试锁定，如果成功返回 YES，否则返回 NO
- (BOOL)lockWhenCondition:(NSInteger)condition beforeDate:(NSDate *)limit;
// 锁的名称，可用于调试
@property (nullable, copy) NSString *name;@end

dispatch_semaphore

semaphore叫做”信号量”
信号量的初始值，可以用来控制线程并发访问的最大数量
信号量的初始值为1，代表同时只允许1条线程访问资源，保证线程同步

dispatch_semaphore_create(5);
// 如果信号量的值 > 0，就让信号量的值减1，然后继续往下执行代码
// 如果信号量的值 <= 0，就会休眠等待，直到信号量的值变成>0，就让信号量的值减1，然后继续往下执行代码
dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER);
// 让信号量的值+1
dispatch_semaphore_signal(self.semaphore);

dispatch_queue

直接使用GCD的串行队列，也是可以实现线程同步的

dispatch_queue_t queue = dispatch_queue_create("test", DISPATCH_QUEUE_SERIAL);dispatch_sync(queue, ^{// 追加任务1for (int i = 0; i < 2; ++i) {NSLog(@"1---%@",[NSThread currentThread]);}
});dispatch_sync(queue, ^{// 追加任务2for (int i = 0; i < 2; ++i) {NSLog(@"2---%@",[NSThread currentThread]);}
});

@synchronized

@synchronized是对mutex递归锁的封装，
@synchronized(obj)内部会生成obj对应的递归锁，然后进行加锁、解锁操作
使用例子：

//假设有段使用锁的方法是这样写的
- (void)push:(id)element
{[_lock lock];[_elements addObject:element];[_lock unlock];
}

它等同于这样使用@synchronized：

- (void)increment
{@synchronized (self) {[_elements addObject:element];}
}

你可以给任何 Objective-C 对象上加个 @synchronized。那么我们也可以在上面的例子中用 @synchronized(_elements) 来替代 @synchronized(self)，效果是相同的。

@synchronized底层实现

@synchronized block 会变成 objc_sync_enter 和 objc_sync_exit 的成对儿调用。

// 定义 SyncData 结构体
typedef struct SyncData {//我们传给 @synchronized 的对象id object;//与 object 关联的递归锁                     recursive_mutex_t mutex;    //指向下一个 SyncData 对象的指针，形成一个链表结构    struct SyncData* nextData;   //当前使用或等待这个 SyncData 对象锁的线程数量   int threadCount;                
} SyncData;// 定义 SyncList 结构体
typedef struct SyncList {//指向 SyncData 链表头部的指针SyncData *data;                //一个自旋锁，用于防止多个线程并发修改这个列表 spinlock_t lock;                
} SyncList;// 定义宏和全局变量//定义了数组的大小（16）
#define COUNT 16 // HASH(obj) 是一个哈希函数，将对象的指针地址转换为数组的索引。这个哈希函数通过右移对象指针五位，再与 15（即 COUNT - 1）进行按位与操作来计算索引。
#define HASH(obj) ((((uintptr_t)(obj)) >> 5) & (COUNT - 1))// LOCK_FOR_OBJ(obj) 宏获取与对象关联的锁
#define LOCK_FOR_OBJ(obj) sDataLists[HASH(obj)].lock // LIST_FOR_OBJ(obj) 宏获取与对象关联的 SyncData 链表头
#define LIST_FOR_OBJ(obj) sDataLists[HASH(obj)].data //SyncList结构体数组，大小为 16
static SyncList sDataLists[COUNT];

一开始，我们有一个 struct SyncData 的定义。这个结构体包含一个 object（即我们传给 @synchronized 的对象）和一个关联的 recursive_mutex_t，它就是那个跟 object 关联在一起的锁。每个 SyncData 也包含一个指向另一个 SyncData 对象的指针，叫做 nextData，所以你可以把每个 SyncData 结构体看作是链表中的一个元素。最后，每个 SyncData 包含一个 threadCount，这个 SyncData 对象中的锁会被一些线程使用或等待，threadCount 就是此时这些线程的数量。它很有用处，因为 SyncData 结构体会被缓存，threadCount==0 就暗示了这个 SyncData 实例可以被复用。

下面是 struct SyncList 的定义。正如我在上面提过，你可以把 SyncData 当做是链表中的节点。每个 SyncList 结构体都有个指向 SyncData 节点链表头部的指针，也有一个用于防止多个线程对此列表做并发修改的锁。

上面代码块的最后一行是 sDataLists 的声明 - 一个 SyncList 结构体数组，大小为 16。通过定义的一个哈希算法将传入对象映射到数组上的一个下标。值得注意的是这个哈希算法设计得很巧妙，是将对象指针在内存的地址转化为无符号整型并右移五位，再跟 0xF 做按位与运算，这样结果不会超出数组大小。LOCK_FOR_OBJ(obj) 和 LIST_FOR_OBJ(obj) 这两个宏就更好理解了，先是哈希出对象的数组下标，然后取出数组对应元素的 lock 或 data。一切都是这么顺理成章哈。

当你调用 objc_sync_enter(obj) 时，它用 obj 内存地址的哈希值查找合适的 SyncData，然后将其上锁。当你调用 objc_sync_exit(obj) 时，它查找合适的 SyncData 并将其解锁。

源码：

BOOL objc_sync_try_enter(id obj)
{BOOL result = YES;if (obj) {SyncData* data = id2data(obj, SyncKind::atSynchronize, ACQUIRE);ASSERT(data);result = data->mutex.tryLock();} else {// @synchronized(nil) does nothingif (DebugNilSync) {_objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");}objc_sync_nil();if (DebugNilSync == Fatal)_objc_fatal("@synchronized(nil) is fatal");}return result;
}// End synchronizing on 'obj'. 
// Returns OBJC_SYNC_SUCCESS or OBJC_SYNC_NOT_OWNING_THREAD_ERROR
int objc_sync_exit(id obj)
{int result = _objc_sync_exit_kind(obj, SyncKind::atSynchronize);if (result != OBJC_SYNC_SUCCESS)OBJC_DEBUG_OPTION_REPORT_ERROR(DebugSyncErrors,"objc_sync_exit(%p) returned error %d", obj, result);return result;
}

当一个对象在 @synchronized block 当中被释放或设为 nil 时会发生什么
会注意到 objc_sync_enter 里面没有 retain 和 release。所以它要么没有保持传递给它的对象，要么或是在 ARC 下被编译。我们可以用下面的代码来做个测试：

NSDate *test = [NSDate date];
//打印 test 的 retainCount，它应当是 1。
NSLog(@"%@", @([test retainCount]));@synchronized (test) {//进入 @synchronized 块，并打印 test 的 retainCount。
//如果 @synchronized 对 test 进行了 retain，retainCount 应为 2。否则，仍为 1。NSLog(@"%@", @([test retainCount]));
}

运行结果显示两次输出都是 1，这表明 @synchronized 没有对传入的对象进行 retain 操作。
@synchronized 块中没有 retain 操作，对象在同步块内被释放后，其内存地址可能被重用。这会导致其他线程在同步同一地址的对象时发生阻塞。
但是这是设计者预见并接受的情况，因为在内存地址相同的情况下，阻塞等待确保了同步块的正确性。添加 retain 操作可能会增加复杂性和性能开销，但没有特别好的替代方案来避免此问题。

假如对象在 “synchronized block” 中被设成 nil 呢

NSString *test = @"test";
@try {//给 test 分配一个锁并锁定它。objc_sync_enter(test);//然后将test设为 nil。test = nil;
} @finally {//调用 objc_sync_exit(test)。因为 test 已被设为 nil，传递给 objc_sync_exit 的是 nil，这会导致锁不会被解锁或释放。objc_sync_exit(test);   
}

在 @synchronized 块中将对象设为 nil 的潜在问题：传递 nil 给objc_sync_exit是一个空操作，导致锁不会被释放。

在 @synchronized 块中将对象设为 nil 不会导致死锁，因为编译器确保 objc_sync_enter 和 objc_sync_exit 传入的是相同对象。
如果传递给 @synchronized 的对象为 nil，不会获得任何锁，代码不会是线程安全的。

这个机制确保了在 @synchronized 块中将对象设为 nil 时不会导致锁未释放的问题。
验证了 @synchronized 在这种情况下的正确性，确保了多线程环境下的线程安全性。

  • 你调用 sychronized 的每个对象，Objective-C runtime 都会为其分配一个递归锁并存储在哈希表中。
  • 如果在 sychronized 内部对象被释放或被设为 nil 看起来都 OK。不过这没在文档中说明，所以我不会再生产代码中依赖这条。
  • 注意不要向你的 sychronized block 传入 nil！这将会从代码中移走线程安全。你可以通过在 objc_sync_nil 上加断点来查看是否发生了这样的事情。
@synchronized(id)参数问题

有如下代码：

- (void)lg_crash{for (int i = 0; i < 200000; i++) {dispatch_async(dispatch_get_global_queue(0, 0), ^{@synchronized (_testArray) {_testArray = [NSMutableArray array];}});}
}

_testArray在某个时刻可能会变为nil，而当_testArray变为nil时，多线程下的操作会导致@synchronized传入的参数为nil而调用objc_sync_nil函数，也就没有了加锁的效果了，从而导致崩溃的出现。
所以我们在使用@synchronized确保多线程数据安全的时候，要保证传入的绝对不能如上例子为nil的情况。修改成如下则不会再有问题：

- (void)lg_crash{for (int i = 0; i < 200000; i++) {dispatch_async(dispatch_get_global_queue(0, 0), ^{@synchronized (self) {_testArray = [NSMutableArray array];}});}
}

atomic

  • atomic用于保证属性setter、getter的原子性操作，相当于在getter和setter内部加了线程同步的锁
  • 它并不能保证使用属性的过程是线程安全的, 只能保证存取值的完整性

pthread_rwlock：读写锁

pthread_rwlock经常用于文件等数据的读写操作，需要导入头文件#import <pthread.h>
iOS中的读写安全方案需要注意一下场景：（多读单写）

  1. 同一时间，只能有1个线程进行写的操作
  2. 同一时间，允许有多个线程进行读的操作
  3. 同一时间，不允许既有写的操作，又有读的操作

锁的性能比较

性能从高到低排序

  1. os_unfair_lock
  2. OSSpinLock
  3. dispatch_semaphore
  4. pthread_mutex
  5. dispatch_queue(DISPATCH_QUEUE_SERIAL)
  6. NSLock
  7. NSCondition
  8. pthread_mutex(recursive)
  9. NSRecursiveLock
  10. NSConditionLock
  11. @synchronized

补充

CPU抢占

CPU 由操作系统统一进行分配，每个进程根据进程优先级的高低都有机会得到 CPU，但是，如果运行时间超过了一定的时间，操作系统会暂停该进程，将 CPU 资源分配给其他等待运行的进程。这种 CPU 的分配方式即所谓的** 抢占式**，操作系统可以强制剥夺 CPU 资源并且分配给它认为目前最需要的进程，如果操作系统分配给每个进程的时间都很短，即 CPU 在多个进程间快速的切换，从而造成了很多进程在同时运行的假象，这个就是并行的实质。

相关文章：

  • 北京网站建设多少钱？
  • 辽宁网页制作哪家好_网站建设
  • 高端品牌网站建设_汉中网站制作
  • 模型训练套路(一）
  • [数据集][目标检测]街道乱堆垃圾检测数据集VOC+YOLO格式94张1类别
  • 【数学建模】2024数学建模国赛B题（word论文+matlab）：生产过程中的决策问题
  • C++ STL-List容器概念及应用方法详解
  • 2024年高教社杯数学建模国赛C题超详细解题思路分析
  • Linux 一个简单的中断信号实现
  • 力扣100题——子串
  • 经验笔记：SSL证书
  • Stream插件相关的用法
  • 操作系统概述及特征
  • 回溯——7.子集II
  • 【蓝桥杯嵌入式（一）程序框架和调度器】
  • 《机器学习》 基于SVD的矩阵分解 推导、案例实现
  • AI基础 L1 Introduction to Artificial Intelligence
  • k8s技术架构
  • Angular js 常用指令ng-if、ng-class、ng-option、ng-value、ng-click是如何使用的？
  • Javascript弹出层-初探
  • MySQL-事务管理（基础）
  • PV统计优化设计
  • Vue 2.3、2.4 知识点小结
  • 阿里云容器服务区块链解决方案全新升级 支持Hyperledger Fabric v1.1
  • 从零到一：用Phaser.js写意地开发小游戏（Chapter 3 - 加载游戏资源）
  • 动手做个聊天室，前端工程师百无聊赖的人生
  • 码农张的Bug人生 - 初来乍到
  • 如何实现 font-size 的响应式
  • 译自由幺半群
  • 云栖大讲堂Java基础入门（三）- 阿里巴巴Java开发手册介绍
  • Salesforce和SAP Netweaver里数据库表的元数据设计
  • 曜石科技宣布获得千万级天使轮投资，全方面布局电竞产业链 ...
  • ​1：1公有云能力整体输出，腾讯云“七剑”下云端
  • ​2020 年大前端技术趋势解读
  • ​Z时代时尚SUV新宠：起亚赛图斯值不值得年轻人买？
  • # Panda3d 碰撞检测系统介绍
  • (02)Cartographer源码无死角解析-(03) 新数据运行与地图保存、加载地图启动仅定位模式
  • （3）llvm ir转换过程
  • （3）医疗图像处理：MRI磁共振成像-快速采集--(杨正汉）
  • （51单片机）第五章-A/D和D/A工作原理-A/D
  • (Python第六天)文件处理
  • （更新）A股上市公司华证ESG评级得分稳健性校验ESG得分年均值中位数（2009-2023年.12）
  • （数据结构）顺序表的定义
  • （一）VirtualBox安装增强功能
  • *ST京蓝入股力合节能 着力绿色智慧城市服务
  • *算法训练（leetcode）第四十七天 | 并查集理论基础、107. 寻找存在的路径
  • .NET Compact Framework 多线程环境下的UI异步刷新
  • .NET Core使用NPOI导出复杂，美观的Excel详解
  • .Net Framework 4.x 程序到底运行在哪个 CLR 版本之上
  • .NET MVC第三章、三种传值方式
  • .NET 解决重复提交问题
  • .NET_WebForm_layui控件使用及与webform联合使用
  • .Net7 环境安装配置
  • @Autowired和@Resource装配
  • @vue-office/excel 解决移动端预览excel文件触发软键盘
  • [\u4e00-\u9fa5] //匹配中文字符
  • []error LNK2001: unresolved external symbol _m
  • [Android]将私钥（.pk8）和公钥证书（.pem/.crt）合并成一个PKCS#12格式的密钥库文件