Android 线程死锁问题分析

于 2024-04-08 15:20:04 发布
阅读量284 收藏
点赞数 1
文章标签： android gitee
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u011044707/article/details/137510688
版权 
====================================================================================================================================================
|| pid: 333, tid: 333,
|| backtrace:
||     #00 pc 00019d74  /system/lib/libc.so (syscall+28)
||     #01 pc 0001d145  /system/lib/libc.so (__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+88)
||     #02 pc 0006457d  /system/lib/libc.so (NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*)+156)
||     #03 pc 00061185  /vendor/lib/librtk_tvapi.so (VSCControlImpl::RegisterObserver(rtk::tv::api::IVSCControlObserver*)+14)
||     #04 pc 0004409b  /vendor/lib/librtk_tvservice.so (android::TvService::VSC::InitalDatas()+86)
||     #05 pc 00044369  /vendor/lib/librtk_tvservice.so (android::TvService::VSC::VSC(android::sp<android::TvService> const&, int, int, android::sp<android::IVSCClient> const&, unsigned int)+168)
||     #06 pc 0003ab7b  /vendor/lib/librtk_tvservice.so (android::TvService::createVSC(android::sp<android::IVSCClient> const&)+102)
||     #07 pc 00049cd5  /vendor/lib/librtk_tvsystem.so (android::BnTvService::onTransact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+704)
||     #08 pc 00029ed7  /system/lib/vndk-28/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+70)
||     #09 pc 0002f2bb  /system/lib/vndk-28/libbinder.so (android::IPCThreadState::executeCommand(int)+410)
||     #10 pc 0002f047  /system/lib/vndk-28/libbinder.so (android::IPCThreadState::getAndExecuteCommand()+106)
||     #11 pc 0002f56f  /system/lib/vndk-28/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+38)
||     #12 pc 000011df  /vendor/bin/tvservice (main+150)
||     #13 pc 0008bbf5  /system/lib/libc.so (__libc_init+48)
||     #14 pc 00001127  /vendor/bin/tvservice (_start_main+46)
||     #15 pc 00000306  <anonymous:b3328000>
|| 
|| 
|| bool VSCControlImpl::RegisterObserver(IVSCControlObserver* pObs)
|| {
||     Mutex::Autolock autoLock(m_obsMutex);
||     if (!pObs) return false;
|| 
||     ObsLstItor itor, itorEnd = m_ObsLst.end();
||     itor = std::find(m_ObsLst.begin(), itorEnd, pObs);
||     if (itor != itorEnd) return false;
||     pObs->AddRef();
||     m_ObsLst.push_back(pObs);
||     return true;
|| }
|| 拿不到 m_obsMutex
||================================================================================================================================================
|| 
|| pid: 333, tid: 2987
|| backtrace:
||     #00 pc 00019d74  /system/lib/libc.so (syscall+28)
||     #01 pc 0001d145  /system/lib/libc.so (__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+88)
||     #02 pc 0006457d  /system/lib/libc.so (NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*)+156)
||     #03 pc 000620a3  /vendor/lib/librtk_tvapi.so (VSCControlImpl::Notify(VSCControl::OBS_EVENT, __VIDEO_WID_T, bool)+30)
||     #04 pc 00061581  /vendor/lib/librtk_tvapi.so (VSCControlImpl::SetWinBlank(__VIDEO_WID_T, int, VIDEO_DDI_WIN_COLOR_T)+68)
||     #05 pc 00081305  /vendor/lib/librtk_tvapi.so (TvDisplayControl::AutoWinBlank::SetInOutRegion(__VIDEO_WID_T, __VIDEO_RECT_T, __VIDEO_RECT_T, VIDEO_DDI_WIN_COLOR_T, _TV_HDR_TYPE, _SIG_RATIO_DESCRIPTION)+252)
||     #06 pc 0007e797  /vendor/lib/librtk_tvapi.so (TvDisplayControlImpl::SetInOutRegion(__VIDEO_WID_T, __VIDEO_RECT_T, __VIDEO_RECT_T, VIDEO_DDI_WIN_COLOR_T, _TV_HDR_TYPE, _SIG_RATIO_DESCRIPTION)+126)
||     #07 pc 00044b61  /vendor/lib/librtk_tvservice.so (android::TvService::VSC::SetInOutRegion(__VIDEO_WID_T, __VIDEO_RECT_T, __VIDEO_RECT_T, VIDEO_DDI_WIN_COLOR_T, _TV_HDR_TYPE, _SIG_RATIO_DESCRIPTION*)+84)
||     #08 pc 00072075  /vendor/lib/librtk_tvsystem.so (android::BnVSC::onTransact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+1208)
||     #09 pc 00029ed7  /system/lib/vndk-28/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+70)
||     #10 pc 0002f2bb  /system/lib/vndk-28/libbinder.so (android::IPCThreadState::executeCommand(int)+410)
||     #11 pc 0002f047  /system/lib/vndk-28/libbinder.so (android::IPCThreadState::getAndExecuteCommand()+106)
||     #12 pc 0002f56f  /system/lib/vndk-28/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+38)
||     #13 pc 00043aed  /system/lib/vndk-28/libbinder.so (android::PoolThread::threadLoop()+12)
||     #14 pc 0000bfd3  /system/lib/vndk-sp-28/libutils.so (android::Thread::_threadLoop(void*)+166)
||     #15 pc 00063a05  /system/lib/libc.so (__pthread_start(void*)+22)
||     #16 pc 0001df95  /system/lib/libc.so (__start_thread+22)
||  bool AutoWinBlank::SetInOutRegion(VIDEO_WID_T wId,
||                                    VIDEO_RECT_T inRegion,
||                                    VIDEO_RECT_T outRegion,
||                                    VIDEO_DDI_WIN_COLOR_T color,
||                                    TV_HDR_TYPE HDRType,
||                                    SIG_RATIO_DESCRIPTION sigRatio)
||  {
||      Mutex::Autolock autoLock(&m_statusLock);
||      StateLstItor iter = m_stateLst.find(wId);
||      if (iter == m_stateLst.end())
||          return false;
||  
||      bool bEnaWinBlank = memcmp(&inRegion, &iter->second->inputRegion, sizeof(VIDEO_RECT_T)) != 0 ||
||                          HDRType != iter->second->HDRType;
||  
||      bool bOutputRegionOnly = inRegion.w == 0 || inRegion.h == 0;
||  
||      if (bEnaWinBlank)
||          m_pDisCtrl->SetVSCWinBlank(wId, true, color);
||  
||      if (!bOutputRegionOnly)
||          m_pDisCtrl->SetInputRegion(wId, inRegion, HDRType, sigRatio);
||  
||      m_pDisCtrl->SetOutputRegion(wId, outRegion);
||  
||      if ((!bOutputRegionOnly)
||  #ifdef ENABLE_MHEG5            
||              && ((RtMHEG5IsStarted() == false) ||
||                  ((RtMHEG5IsStarted() == true) && ((RtMHEG5IsVideoActivate() == true) || (RtMHEG5IsIframeActivate() == true))))
||  #endif
||          )
||          m_pDisCtrl->SetVSCWinBlank(wId, false, color);
||  
|| 
|| bool TvDisplayControlImpl::SetVSCWinBlank(VIDEO_WID_T wId, int32_t bOnOff, VIDEO_DDI_WIN_COLOR_T color)
|| {
||     if (m_pVSCCtrl == NULL)
||         return false;
||     return m_pVSCCtrl->SetWinBlank(wId, bOnOff, color);
|| 	
|| 	
|| 	
|| 	
|| 	bool VSCControlImpl::SetWinBlank(VIDEO_WID_T wId, int32_t bOnOff, VIDEO_DDI_WIN_COLOR_T color)
|| {
||     RTD_AP_LOG(RTD_AP_LOG_LEVEL_I, RTD_AP_LOG_MODULE_PERFORMANCE, "%s wId=%d, bOnOff=%d", __FUNCTION__, wId, bOnOff);
|| 
||     if (bOnOff == true)
||         Notify(OBS_EVENT_MUTE, wId, true);==========================《《《《《
|| 
||     if (bOnOff == 0)
||         PERF_RECORD(PERF_RECORD_MODULE_VSC, PERF_RECORD_ID_T5, PERF_RECORD_TYPE_ALL, RECODRD_STATE_START);
||     return RHAL_VSC_SetWinBlank(wId, bOnOff, color) == API_OK;
|| }
|| 
|| }
|| 
|| 
|| bool VSCControlImpl::Notify(OBS_EVENT event, VIDEO_WID_T wId, bool bEnable)
|| {
||     Mutex::Autolock autoLock(m_obsMutex);
|| 	
|| 
|| m_statusLock拿到，但拿不到 m_obsMutex
|| 	
||=====================================================================================================================================================	
|| 	
|| pid: 333, tid: 573
|| backtrace:
||     #00 pc 00019d74  /system/lib/libc.so (syscall+28)
||     #01 pc 0001d145  /system/lib/libc.so (__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+88)
||     #02 pc 0006457d  /system/lib/libc.so (NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*)+156)
||     #03 pc 0008114b  /vendor/lib/librtk_tvapi.so (TvDisplayControl::AutoWinBlank::ResetState(__VIDEO_WID_T)+6)
||     #04 pc 000814e7  /vendor/lib/librtk_tvapi.so (TvDisplayControl::ObserverMgr::VSCObsImpl::ConnectStartNotify(__VIDEO_WID_T, VSC_INPUT_SRC_INFO, VSC_OUTPUT_MODE, _TV_SOURCE, SOURCE_TYPE)+12)
||     #05 pc 00061fc9  /vendor/lib/librtk_tvapi.so (VSCControlImpl::Notify(VSCControl::OBS_EVENT, __VIDEO_WID_T, VSC_INPUT_SRC_INFO, VSC_OUTPUT_MODE, _TV_SOURCE, SOURCE_TYPE)+108)
||     #06 pc 00061ebf  /vendor/lib/librtk_tvapi.so (VSCControlImpl::ConnectInternal(__VIDEO_WID_T, VSC_INPUT_SRC_INFO, VSC_OUTPUT_MODE, _TV_SOURCE, SOURCE_TYPE)+86)
||     #07 pc 00061e37  /vendor/lib/librtk_tvapi.so (VSCControlImpl::TryToConnect(_TV_SOURCE)+130)
||     #08 pc 00062e4b  /vendor/lib/librtk_tvapi.so (VSCControl::ObserverMgr::VFEObsImpl::VFENotify(_VFE_MESSAGE, _TV_SOURCE)+48)
||     #09 pc 0007b0e3  /vendor/lib/librtk_tvapi.so (CTvSourceControl::NotifyVFE(_VFE_MESSAGE, _TV_SOURCE)+78)
||     #10 pc 0007aea3  /vendor/lib/librtk_tvapi.so (CTvSourceControl::ActivateSource(_TV_SOURCE)+138)
||     #11 pc 0007c0ad  /vendor/lib/librtk_tvapi.so (CTvSourceControl::ChangeSource(_TV_SOURCE, _TV_SOURCE)+164)
||     #12 pc 0007d135  /vendor/lib/librtk_tvapi.so (CTvSourceControl::LooperMgr::onMessageReceived(android::sp<android::RTMessage> const&)+552)
||     #13 pc 0007cee1  /vendor/lib/librtk_tvapi.so (android::RTHandlerReflector<CTvSourceControl::LooperMgr>::onMessageReceived(android::sp<android::RTMessage> const&)+48)
||     #14 pc 00007785  /vendor/lib/librtk_foundation.so (android::RTHandler::deliverMessage(android::sp<android::RTMessage> const&)+24)
||     #15 pc 000094e5  /vendor/lib/librtk_foundation.so (android::RTMessage::deliver()+60)
||     #16 pc 00007d75  /vendor/lib/librtk_foundation.so (android::RTLooper::loop()+328)
||     #17 pc 0000c04b  /system/lib/vndk-sp-28/libutils.so (android::Thread::_threadLoop(void*)+286)
||     #18 pc 00063a05  /system/lib/libc.so (__pthread_start(void*)+22)
||     #19 pc 0001df95  /system/lib/libc.so (__start_thread+22)
|| 	
|| 	bool VSCControlImpl::TryToConnect(TV_SOURCE tvSrc)
|| {
||     Mutex::Autolock autoLock(m_tryToConnectMutex);
|| 
||     INPUT_INFO inputInfo;
||     memset(&inputInfo, 0, sizeof(INPUT_INFO));
|| 
||     for (int i = VIDEO_WID_0 ; i <= VIDEO_WID_1 ; i++)
||     {
||         if (m_statusMgr.GetTempVSCInfo((VIDEO_WID_T)i, m_pResourceClientCallbackImpl)->GetConnected())
||         {
||             m_statusMgr.GetTempVSCInfo((VIDEO_WID_T)i, m_pResourceClientCallbackImpl)->GetInputInfo(&inputInfo);
||             if (memcmp(&inputInfo.tvSrc, &tvSrc, sizeof(TV_SOURCE)) == 0)
||                 ConnectInternal((VIDEO_WID_T)i, inputInfo.vscInput, inputInfo.outputMode, inputInfo.tvSrc, inputInfo.srcType);
||         }
||     }
||     return true;
|| }
|| 
|| bool VSCControlImpl::ConnectInternal(VIDEO_WID_T wId, VSC_INPUT_SRC_INFO_T vscInput, VSC_OUTPUT_MODE_T outputmode, TV_SOURCE tvSrc, SOURCE_TYPE srcType)
|| {
||     Mutex::Autolock autoLock(m_connectInternalMutex);
|| 
||     if (m_statusMgr.GetVSCInfo(wId, m_pResourceClientCallbackImpl)->GetConnected())
||         return false;
|| 
||     Notify(OBS_EVENT_CONNECT_START, wId, vscInput, outputmode, tvSrc, srcType);
|| 
||     AcquireVdec(wId, tvSrc);
||     RHAL_VSC_Open(wId);
||     RHAL_VSC_Connect(wId, vscInput, outputmode);
|| 
||     INPUT_INFO inputInfo;
||     memset(&inputInfo, 0, sizeof(INPUT_INFO));
||     inputInfo.vscInput = vscInput;
||     inputInfo.outputMode = outputmode;
||     inputInfo.tvSrc = tvSrc;
||     inputInfo.srcType = srcType;
||     m_statusMgr.GetVSCInfo(wId, m_pResourceClientCallbackImpl)->SetInputInfo(&inputInfo);
||     m_statusMgr.GetVSCInfo(wId, m_pResourceClientCallbackImpl)->SetConnected(true);
|| 
||     Notify(OBS_EVENT_CONNECT_END, wId, vscInput, outputmode, tvSrc, srcType);
||     return true;
|| }
|| 
|| 
|| bool VSCControlImpl::Notify(OBS_EVENT event, 
||                             VIDEO_WID_T wId, 
||                             VSC_INPUT_SRC_INFO_T vscInput, 
||                             VSC_OUTPUT_MODE_T outputmode, 
||                             TV_SOURCE tvSrc, 
||                             SOURCE_TYPE srcType)
|| {
||     Mutex::Autolock autoLock(m_obsMutex);
||     if (m_ObsLst.size() <= 0)
||         return false;
|| 
||     for (ObsLstItor itor = m_ObsLst.begin() ; itor != m_ObsLst.end() ; ++itor)
||     {
||         switch(event)
||         {
||             case OBS_EVENT_CONNECT_START:
||                 (*itor)->ConnectStartNotify(wId, vscInput, outputmode, tvSrc, srcType);
||                 break;
|| 
|| 
||         bool ConnectStartNotify(VIDEO_WID_T wId, VSC_INPUT_SRC_INFO_T vscInput, VSC_OUTPUT_MODE_T outputmode, TV_SOURCE tvSrc, SOURCE_TYPE srcType)
||         {
||             m_pOutClass->m_pDisCtrl->AutoWinBlankResetState(wId);
||             return true;
||         }
|| 		
|| 		
|| 		void TvDisplayControlImpl::AutoWinBlankResetState(VIDEO_WID_T wId)
|| {
||     if (m_pAutoWinBlank != NULL)
||         m_pAutoWinBlank->ResetState(wId);
|| }
|| 
|| 
|| void AutoWinBlank::ResetState(VIDEO_WID_T wId)
|| {
||     Mutex::Autolock autoLock(&m_statusLock);//wait
||     StateLstItor iter = m_stateLst.find(wId);
||     if (iter == m_stateLst.end())
||         return;
|| 
||     iter->second->inputRegion = {0, 0, 0, 0};
||     iter->second->outputRegion = {0, 0, 0, 0};
||     iter->second->sigRatio = {SIG_RATIO_TYPE_NULL, SIG_ASPECT_RATIO_1_1, 0};
||     iter->second->HDRType = TV_HDR_TYPE_NORMAL;
|| }
|| 
|| m_obsMutex拿到，但拿不到m_statusLock
||==================================================================================================================================================
|| 
||    status
||  A  get m_statusLock  ----> wait m_obsMutex
||  B  get m_obsMutex    ----> wait m_statusLock
|| 
|| 所以两个线程一直在无限等待
|| 
|| 
|| 修改方法，采用tryLock机制。
|| 
|| static const int LockRetries = 30
|| static const int LockSleepUs = 20000
|| static bool tryLock(Mutex& m_statusLock)
|| {
||     bool locked = false;
||     for (int i = 0; i < kDumpLockRetries; ++i) {
||         if (m_statusLock.tryLock() == NO_ERROR) {
||             locked = true;
||             break;
||         }
||         usleep(kDumpLockSleepUs);
||     }
||     return locked;
|| }
|| 
|| 
|| void AutoWinBlank::ResetState(VIDEO_WID_T wId)
|| {
||     //Mutex::Autolock autoLock(&m_statusLock);
||     bool locked = tryLock(m_statusLock);
||     StateLstItor iter = m_stateLst.find(wId);
||     if (iter == m_stateLst.end())
||         return;
|| 
||     iter->second->inputRegion = {0, 0, 0, 0};
||     iter->second->outputRegion = {0, 0, 0, 0};
||     iter->second->sigRatio = {SIG_RATIO_TYPE_NULL, SIG_ASPECT_RATIO_1_1, 0};
||     iter->second->HDRType = TV_HDR_TYPE_NORMAL;
||     if (locked) m_statusLock.unlock();
|| }
||=====================

陈太闲
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
android 互斥锁 Mutex::Autolock
大海牛的专栏
06-10 1387
小白一枚，文章仅供参考，有错误请帮忙指出 前提： 要理解Mutex:: Autolock 的前提，需要知道C++的栈对象，在方法执行完之后，方法弹栈，对象会自动被回收，然后析构函数会被调用。 代码 使用实例 void test() { // 定义位置： system/core/libutis/include/utils/Mutex.h // 自动管理互斥，在方法调用结束使，对象存在栈中，会被自动回收，会调用对象的析构函数，会自动解锁。 Mutex::Autolock _l(gProc
通过Android trace文件分析死锁ANR实例过程
01-20
对于从事Android开发的人来说，遇到ANR(Application Not Responding)是比较常见的问题。一般情况下，如果有ANR发生，系统都会在/data/anr/目录下生成trace文件，通过分析trace文件，可以定位产生ANR的原因。产生ANR的原因有很多，比如CPU使用过高、事件没有得到及时的响应、死锁等，下面将通过一次因为死锁导致的ANR问题，来说明如何通过trace文件分析ANR问题。 对应的部分trace文件内容如下： “PowerManagerService” prio=5 tid=24 MONITOR | group=”main” sCount=1 dsCou
进程死锁
u013102349的博客
02-09 303
死锁概念死锁，是指多个进程循环等待它方占有的资源而无限期地僵持下去的局面。计算机产生死锁的根本原因是资源有限且操作不当。产生死锁的必要条件(1)互斥条件。即某个资源在一段时间内只能由一个进程占有，不能同时被两个或两个以上的进程占有。(2)不可抢占条件。进程所获得的资源在未使用完毕之前，资源申请者不能强行地从资源占有者手中夺取资源，而只能由该资源的占有者进程自行释放。(3)占有且申请条件。进程至少已...
Android死锁初探
kuangben2000的博客
05-01 544
Android死锁初探 https://zhuanlan.zhihu.com/p/152049739 一、什么是死锁 说到死锁，大家可能都不陌生，每次遇到死锁，总会让计算机产生比较严重的后果，比如资源耗尽，界面无响应等。 死锁的精确定义： 集合中的每一个进程（或线程）都在等待只能由本集合中的其他进程（或线程）才能引发的事件，那么该组进程是死锁的。 对于这个定义大家可能有点迷惑，换一种通俗的说法就是： 死锁是指两个或两个以上的线程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，
android 死锁案例,Watchdog死锁实例分析
weixin_35695430的博客
05-28 1070
更多干货，请关注微信公众号: tmac_loverjava1. 什么是Watchdog对Android稍微有所了解的朋友应该都听过ANR这个东西，它的全称是ApplicationNotResponding, 也就是由于某种缘由应用程序卡住了，没有任何响应。android其实在framework里，也会有相似ANR的东西产生，咱们能够叫它是“SystemNotResponding”, 形成这个的缘由...
android死锁解决方案,【线程死锁】Android多线程死锁产生的原因以及如何避免
weixin_42594419的博客
05-25 1987
一、死锁定义1、生活中的列子两人吃饭，但只有一双筷子，2人轮流吃(同时拥有2只筷子才能吃)，某个时候一人拿了左筷子，一人拿了右筷子，两人同时占用一个资源，等待另一个资源，这时候甲等乙吃完并释放他所占的筷子，而乙同样等待甲吃完并释放他所占有的筷子，这样就陷入了一个死循环，谁也无法继续吃饭。这就是死锁2、定义指多线程因竞争资源而造成的一种僵局(互相等待)若无外力作用这些进程都将无法向前推进 。二、死锁...
Android源码——多线程断点下载源码.zip
10-08
2. **线程安全**：处理文件读写和状态更新时，需确保线程安全，避免竞态条件和死锁。 3. **异常处理**：应处理各种可能的网络错误和IO异常，确保下载的健壮性。 4. **性能优化**：根据网络状况调整线程数量，避免...
Android平台智能终端开机定屏问题研究与分析.pdf
09-21
如果某个应用在启动时发生了异常，比如内存泄漏、线程死锁或者资源冲突，可能会影响SurfaceFlinger的正常工作，从而造成开机定屏。因此，开发者需要对应用代码进行严格审查，确保没有潜在的运行时错误。 针对开机定...
java线程分析android project例子
09-27
在Android开发中，Java线程的使用是必不可少的，特别是在构建复杂的、响应性强的应用时。本文将深入探讨在Android项目中如何使用Java线程，并基于`TestThread`这个示例来解析`sleep()`, `join()`, `yield()`, `wait...
线程与互斥锁的应用
01-04
用两个线程，一个线程echo，一个线程cat来读取手机的imei
Android/Linux线程死锁demo分析(九十六)
Android系统攻城狮
12-12 349
1.线程死锁 #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <unistd.h> pthread_mutex_t m; void *runodd(void *d){ int i=0; for(i=1;;i+=2){ pthread_mutex_lock(&m); printf("奇数：%d\n",i); usleep(100); pthr.
android 线程等待导致死锁
T_Y_F_的博客
10-05 1298
android 线程等待导致死锁
Android死锁处理
SecularBird的专栏
03-19 3454
什么是死锁 android死锁的处理方式 Android系统的Framework层有一个WatchDog用于定期检测关键系统服务是否发生死锁。WatchDog功能主要是分析系统核心服务和重要线程是否处于Blocked状态。 源码见：WatchDog 基本原理就是定期轮询检测系统中核心的线程的状态 检测到卡死后，将相关对应的线程，进程及其他软硬件信息输出。 Android开发过程中死锁分析方法 在Android开发中最容易碰到的死锁表现形式ANR。产生ANR的原因很多，死锁只是其中一种。如果ANR发生，对应
android死锁解决方案,死锁 · Android 开发知识技能点指南 · 看云
weixin_29275257的博客
05-25 838
#死锁---当线程需要同时持有多个锁时，有可能产生死锁。考虑如下情形：线程A当前持有互斥所锁lock1，线程B当前持有互斥锁lock2。接下来，当线程A仍然持有lock1时，它试图获取lock2，因为线程B正持有lock2，因此线程A会阻塞等待线程B对lock2的释放。如果此时线程B在持有lock2的时候，也在试图获取lock1，因为线程A正持有lock1，因此线程B会阻塞等待A对lock1的释放...
死锁案例一
这个时代，作为程序员可能要学习小程序
02-27 224
点击上方关注 “终端研发部”设为“星标”，和你一起掌握更多数据库知识一、前言死锁，其实是一个很有意思也很有挑战的技术问题，大概每个 DBA 和部分开发同学都会在工作过程中遇见 。关于死锁我会持续写一个系列的案例分析，希望能够对想了解死锁的朋友有所帮助。二、案例分析2.1 环境说明MySQL 5.6 事务隔离级别为 RR。CREATE TABLE `ty` ( `id`int(11) NOT N...
Android多线程死锁定位,Java---多线程之死锁
weixin_29209805的博客
05-26 285
死锁的两种情况：简单的说下单块cpu运行多线程的情况：大家可能平时玩电脑，可以同时挂QQ啊，玩游戏啊，打开文本啊，等等。这里，我们假设是单块cpu。也就是俗称的单核cpu。大家可能会觉得这些软件，这些线程是同时运行的，其实不然，其实在任何一种情况下，电脑都只运行一个线程！只是因为这个单块的cpu内部为我们划分了很多很多的时间块，而这个时间的划分是以纳秒为单位的，也就是说，这个10纳秒我运行这个线程...
android面试-死锁条件
zh1豪的博客
10-25 786
死锁产生的原因，死锁产生的必要条件是什么，如何预防死锁，如何避免死锁，死锁定理？ 死锁产生的原因： 1)竞争资源； 2)进程推进顺序不当。 死锁产生的必要条件： （1）互斥条件：一个资源一次只能被一个进程所使用，即是排它性使用。 （2）不剥夺条件：一个资源仅能被占有它的进程所释放，而不能被别的进程强占。 （3）请求与保持条件：进程已经保持了至少一个资源，但又提出了新的资源要求，而
android死锁问题分析
最新发布
05-13
Android死锁问题通常是由于多线程并发执行时出现的资源竞争引起的。在 Android 系统中，死锁问题通常出现在以下几种情况： 1. 多个线程同时竞争同一个锁资源，导致其中一个线程被阻塞，而其他线程又在等待这个线程释放锁资源，形成死锁。 2. 多个线程之间相互等待对方释放锁资源，形成死锁。 为了避免 Android 死锁问题，我们可以采取以下措施： 1. 避免在主线程中执行耗时操作，这样可以避免主线程被阻塞。 2. 合理使用锁资源，尽量避免出现资源竞争的情况。可以使用 ReentrantLock、ReadWriteLock 等锁机制来避免死锁。 3. 避免在 UI 线程中进行耗时操作，可以将耗时操作放在子线程中执行。 4. 使用线程池来管理线程，避免线程过多或线程过少的情况。 5. 在编写多线程程序时，要多进行测试和调试，及时发现并解决问题。 总之，避免 Android 死锁问题需要我们在编写程序时加强对多线程编程的理解和掌握，以及严格遵守多线程编程的规范。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值