为什么boost::thread_specific_ptr在几秒钟后冻结android ndk

Question

我有一个使用NDK的应用程序，它与java应用程序一起使用共享库。共享库使用下面的线程，并且管理库中的AttachCurrentThread/DeachCurrentThread非常困难，所以我试图使用boost:：thread_specific_ptr来创建一个管理JNIEnv*的类。问题是，如果我在所有应用程序上使用boost:：thread_specific_ptr，那么几秒钟后应用程序就会挂起。有什么建议吗？！？！

更新：我添加了第二个方法，我认为它在引擎盖下非常相似，但有同样的问题。还有gdb堆栈：

boost::detail::thread_data_base::~thread_data_base() at thread.cpp:42 0x72e91b74    
boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, XXX>, boost::_bi::list1<boost::_bi::value<XXX*> > > >::~thread_data() at thread.hpp:91 0x72d69198    
boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, XXX>, boost::_bi::list1<boost::_bi::value<XXX*> > > >::~thread_data() at thread.hpp:91 0x72d691e4    
boost::checked_delete<boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, XXX>, boost::_bi::list1<boost::_bi::value<XXX*> > > > >() at checked_delete.hpp:34 0x72d69230  
boost::detail::sp_counted_impl_p<boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, XXX>, boost::_bi::list1<boost::_bi::value<XXX*> > > > >::dispose() at sp_counted_impl.hpp:78 0x72d72c54 
boost::detail::sp_counted_base::release() at sp_counted_base_spin.hpp:103 0x72c67480    
boost::detail::shared_count::~shared_count() at shared_count.hpp:371 0x72c67550 
~shared_ptr() at shared_ptr.hpp:328 0x72e91a3c  
boost::thread::join_noexcept() at thread.cpp:340 0x72e91a3c 
boost::thread::join() at thread.hpp:751 0x72cda274  

问题似乎在于析构函数，其中i->_M_current为null，我仍在通过boost代码查看真正的问题，但进展缓慢。

  thread_data_base::~thread_data_base()
    {
        for (notify_list_t::iterator i = notify.begin(), e = notify.end();
                i != e; ++i)
        {
            i->second->unlock();
            i->first->notify_all();
        }
        for (async_states_t::iterator i = async_states_.begin(), e = async_states_.end();
                i != e; ++i)
        {
            (*i)->make_ready();
        }
    }

首次尝试

class ThreadJNIEnv
{
private:
    bool        m_bDetach;
    JNIEnv*     m_pJavaEnv;
public:
    ThreadJNIEnv( ) :
        m_pJavaEnv( NULL )
    {
        LOGI( "Attaching Thread" );
        g_pJavaVM->AttachCurrentThread( &m_pJavaEnv, NULL );
        m_bDetach = true;
    }
    ThreadJNIEnv( JNIEnv* pJavaEnv ) :
        m_pJavaEnv( pJavaEnv )
    {
        LOGI( "Attach (main thread): %p ", m_pJavaEnv );
        m_bDetach = false;
    }
    ~ThreadJNIEnv( )
    {
        if( m_bDetach )
        {
            LOGI( "Detaching Thread" );
            g_pJavaVM->DetachCurrentThread( );
        }
    }
    JNIEnv* GetEnv( ) { return m_pJavaEnv; };
};

// Class which manages JNIEnv per thread
boost::thread_specific_ptr<ThreadJNIEnv> g_oJNIEnv;
// Sample thread local data which also hangs the app
boost::thread_specific_ptr<int> g_oValue;
JNIEnv* GetJNIEnv( )
{
    // Do we already have a JNIEnv?
    ThreadJNIEnv* pJNIEnv = g_oJNIEnv.get( );
    if( pJNIEnv == NULL )
    {
        // Create a new JNIEnv (attach the thread)
        g_oJNIEnv.reset( new ThreadJNIEnv( ) );
    }
    return g_oJNIEnv->GetEnv( );
}
jint JNI_OnLoad( JavaVM* vm, void* reserved )
{
    g_pJavaVM = vm;
    g_pJavaVM->GetEnv( (void **)&g_pJniEnv, JNI_VERSION_1_6 );
    // This is a simple one that also exhibits the problem
    g_oValue.reset( new int[10] );
    // Add the main thread environment
    //g_oJNIEnv.reset( new ThreadJNIEnv( pJavaEnv ) );
    LOGI( "JNI_OnLoad called: vm=%p, env=%p", g_pJavaVM, g_pJniEnv );
    return JNI_VERSION_1_6;
}

第二次尝试

void DetachThread( )
{
    LOGI( "Detaching Thread" );
    g_pJavaVM->DetachCurrentThread( );
}
JNIEnv* GetJNIEnv( )
{
    JNIEnv* pJNIEnv = NULL;
    int status = g_pJavaVM->GetEnv( (void **)&pJNIEnv, JNI_VERSION_1_6 );
    switch( status )
    {
        case JNI_EDETACHED:
        {
            LOGI( "Attaching Thread" );
            g_pJavaVM->AttachCurrentThread( &pJNIEnv, NULL );
            boost::this_thread::at_thread_exit( DetachThread );
        }
        break;
        case JNI_OK:
        {
            // Everything is ok
        }
        break;
        case JNI_EVERSION:
        {
            LOGE( "GetEnv: version not supported" );
        }
        break;
    }
    LOGI( "GetJNIEnv: %p", pJNIEnv );
    return pJNIEnv;
}

Answer 1

根据堆栈跟踪，如果我理解正确的话，包含线程的共享指针的销毁从join开始，这看起来很奇怪。在我看来，你的github代码似乎还可以，但如果问题出在boost版本，请尽量避免共享指针，并在那里使用scope_thread或移动构造。